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ABSTRACT 


The Wireless Networks for Industrial Automation-Process Automation (WIA-PA) standard 
is not well known in North America and is a relatively new industrial control system standard 
when compared to WirelessHart and ISAlOO.llA. An evaluation of the WIA-PA standard 
needs to be conducted by Department of Defense and its affiliates to determine whether 
its operation is on par with WirelessHart and ISAlOO.llA. The objective of this thesis 
is to provide a performance analysis of the WIA-PA standard. Utilizing MATLAB, we 
implemented a custom-built WIA-PA system model and measured the end-to-end delay, 
and received packet error rate and timeslot utilization. We expect WIA-PA to perform as 
well as WirelessHart and ISAlOO.llA in multiple network scenarios. We also found that 
due to the limitations of MATLAB, further analysis of the standard should be conducted on 
a network simulator such that network traffic can be properly emulated and the standard’s 
vulnerabilities can be further assessed. 
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CHAPTER 1: 

Introduction 


An industrial control system (ICS) is a broad term that encompasses supervisory control and 
data acquisition (SCADA), distributed control systems (DCS), and other control systems 
that work together to meet industrial objectives [1]. According to the National Institute 
of Standards and Technology (NIST), ICSs “are typically used in electrical, water and 
wastewater, oil and natural gas, chemical, transportation, pharmaceutical, pulp and paper, 
food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable 
goods) industries” [1]. These examples are indicative of the many different applications of 
ICSs in the public and private sectors. As such, ICSs have become an integral part of the 
U.S. cyber infrastructure. 

The Department of Defense (DOD) is one the largest consumers of ICSs in the federal 
government. The DOD has more than 2.5 million unique ICSs [2]. This collection of 
specialized systems is pervasive throughout the DOD’s infrastructure. The adoption of the 
ICS has modernized DOD capabilities and helped automate complex processes. The U.S. 
Navy (USN), both ashore and afloat, utilizes the vast capabilities of the ICS to help “reduce 
facility maintenance costs, reduce energy consumption, and support mission assurance” [3]. 

Early control of industrial processes was maintained through either manual control or the 
utilization of hydraulic systems [4]. As technology has advanced, these manual control 
processes have been replaced with electronically controlled processes. In traditional ICS 
networks, sensors are wired, which restricts their use [5]. Over the last several years, 
control systems have begun to integrate wireless sensor network technology. The use 
of wireless sensor networks (WSNs) in ICSs provides greater flexibility, scalability, and 
inherent intelligent processing [6]. They also provide the ability to automate and monitor 
processes that are either too costly or for which it is too difficult to have wiring installed. 

1.1 Wireless Sensor Networks 

Wireless sensor networks are composed of autonomous sensor networks that are used for 
acquiring data from the physical environment [6]. The sensor devices that compose these 
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networks are usually small in size, have limited computing power, use batteries for power, 
and have an operating range of approximately 10 meters [7]. The main disadvantage of a 
sensor device is the power constraint. The limited power range of a sensor makes the WSN 
incompatible with standard Wi-Fi protocols. This constraint has driven the development of 
new wireless standards for Low-Rate Wireless Personal Area Networks (LR-WPAN). 

The Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard for 
ER-WPAN was released in 2003. IEEE 802.15.4 defines the specifications for the 
physical (PHY) and medium access control (MAC) layers of devices that require low 
battery consumption and have low data rates [7]. There are several different standards that 
aim to meet the requirements of WSNs within an ICS, including WirelessHart, International 
Society of Automation (ISA)lOO.llA, and Wireless Networks for Industrial Automation - 
Process Automation (WIA-PA) [8]. These standards use the PHY/MAC layers specified in 
IEEE 802.15.4 and then build proprietary data link layer (DEE), network layer (NE), and 
application layer (AE) protocols on top. 

1.2 Research Motivations and Objectives 

Two of the most prevalent standards in WSNs for an ICS are WirelessHart and ISAIOO. 11A 
[9]. Both standards are internationally accepted and have been thoroughly researched, as is 
documented in the literature. Major international companies such as Honeywell, Siemens, 
and Emerson have developed wireless instrumentation technology based on WirelessHart 
and ISAIOO. 11 A. 

The WIA-PA standard was first proposed by the Chinese Industrial Wireless Alliance in 
2007. It was approved by the International Electrotechnical Commission (lEC) as an 
international standard (IEC62601Ed.l.0.) in 2011 and is currently in its second revision 
(IEC62601:2016). WIA-PA offers various advantages over WirelessHart and ISAIOO. 11 A. 
WIA-PA adopts adaptive frequency hopping, two-level aggregation, and utilization of a 
mesh-star network topology [10]. WIA-PA utilizes beacons and is able to coexist with 
other beacon-enabled networks, while WirelessHart and ISAIOO. 11A are unable to send or 
understand beacon messages and therefore cannot coexist with beacon-enabled networks [9]. 
WIA-PA’s mesh and star topology allows distributed communication allocation [9]. The 
distributed allocation is completed by the network manager. The network manager allocates 
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resources to the cluster heads, and then the cluster heads allocate resources to the devices 
within their clusters. This is in contrast to WirelessHart where the network manager 
allocates resources to all devices. ISAIOO. 1 lA utilizes a backbone of routers for centralized 
management [9]. WIA-PA also implements static routing with redundant routing devices 
to meet the real-time requirements of an ICS, as compared to source and graph routing 
in WirelessHart and ISAIOO.HA. Graph routing increases the latency of the network; 
therefore, the routing algorithms used in WirelessHart and ISAlOO.l lA must be optimized 
specifically for use with these standards [9]. 

Despite these advantages, the WIA-PA standard is not well known in North America and is 
a relatively new ICS standard when compared to WirelessHart and ISAIOO. 11 A. Although 
it is part of the lEC, there is not an extensive amount of research on WIA-PA documented in 
the literature. The limited research that is available has been conducted by Chinese research 
institutions. Given that the use cases for WIA-PA are extensive [II], an evaluation of the 
WIA-PA standard needs to be conducted by DOD and its affiliates to determine whether its 
operation is on par with WirelessHart and ISAIOO. 11 A. In addition, an analysis of WIA-PA 
would provide further insight into possible future exploitation and vulnerability assessment 
of the standard. 


1.3 Thesis Contributions 

The objective of this thesis is to provide a performance analysis of the WIA-PA standard. 
The contributions of this thesis are as follows: 

• Performance evaluation of WIA-PA on a custom-built system model implemented in 
MATLAB 

• Analysis of results based on the following WIA-PA performance metrics: end-to-end 
delay, received packet error rate, and timeslot utilization 

1.4 Thesis Organization 

The remainder of this thesis is organized as follows: In Chapter 2 we present a review of 
related research involving WIA-PA, WirelessHart, and ISAIOO. 11 A. The IEEE 802.15.4 
protocol and the WIA-PA standard are discussed in Chapter 3. The experimental model 
and analysis of WIA-PA network performance is provided in Chapter 4. In Chapter 5 we 
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present our conclusions and recommendations for future work. Appendix B contains all the 
MATLAB code used for the simulations. 
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CHAPTER 2: 
Research Review 


As technology advances and WSNs begin to be implemented in ICSs, research has been 
executed to develop and test methods to meet the rigorous requirements of real-time indus¬ 
trial processes. In this chapter we review some of the research that has been conducted for 
each of the three international standards for ICS: WirelessHart, ISAIOO. I lA, and WIA-PA. 

2.1 WirelessHart 

In 2008, the lEC approved WirelessHart as an international standard. It is an extension 
of the Highway Addressable Remote Transducer (HART) protocol, which is a wired ICS 
protocol. WirelessHart utilizes graph routing, but leaves the scheduling to be implemented 
by the user. As discussed in Section 1.2, graph routing increases the latency of the 
network. To minimize this latency, the authors of [8], [12], and [13] proposed multiple 
scheduling algorithms to find an optimization that is feasible with the energy constraints 
of WSNs. In [14], the authors proposed the implementation of a forward error correction 
(FEC) scheme, the employment of channel polarization diversity, and a reduction of the 
WirelessHart packet header size. The authors demonstrated that these changes reduced the 
power consumption of the protocol and increased energy efficiency. 

Since WirelessHart utili z es the non-beacon-enabled mode of IEEE 802.15.4 and time divi¬ 
sion multiple access (TDMA), synchronization across the network is of utmost importance. 
Even a slight disparity in timing can have grave consequences in the industrial environ¬ 
ment. The authors of [15] introduced mathematical models to enhance the study of time 
synchronization for WirelessHart, while in [16] and [17], the authors proposed methods to 
improve the synchronization precision of the network. To help with testing and studying 
WirelessHart, several researchers have offered different simulation methods [18], [19]. It is 
important to have multiple ways to evaluate the different standards to ensure their reliability. 


5 




2.2 ISAlOO.llA 

ISAlOO.llA is a standard that was developed in 2009 and gained lEC approval in 2014. 
As with the other WSN standards, ISAlOO.l lA utilizes the 2.4 GHz band of the industrial, 
scientific, and medical (ISM) unlicensed band. IEEE 802.11 uses the same band. The 
authors of [20] showed that an ISAlOO.llA network could operate without degradation 
within radio range of an IEEE 802.11 network. There are many protocols that operate within 
the 2.4 GHz band, which leads to congestion and interference when multiple protocols are 
operating within radio range. To assist with operating in a congested frequency band, [21] 
and [22] studied adaptive channel diversity for ISAlOO.llA and showed that this method 
helps to avoid interference from congestion. 

ISAlOO.llA, as in WirelessHart, utili z es the non-beacon-mode of IEEE 802.15.4 and a 
timeslot scheme for communication. With this comes the need for synchronization and a 
scheduling algorithm to ensure real-time processing. The authors of [23] offered a Traffic- 
Aware Message Scheduling method that improved throughput and end-to-end delay for 
ISAlOO.l 1 A. As for synchronization, [24] proposed a novel self-organized synchronization 
method based on the synchronization patterns of male fireflies found in Southeast Asia. 

2.3 WIA-PA 

The Chinese-developed WSN standard for ICS, WIA-PA, was accepted by the lEC in 
2011 [10]. This standard is the only one of the three that implements the beacon-enabled 
mode of the IEEE 802.15.4 standard. The beacons are used for initial synchronization of 
joining nodes, but the standard also utilizes a time synchronization packet that was pro¬ 
posed in [25]. By using beacons, WIA-PA is compatible with other beacon networks, as 
discussed in [9]. This allows WIA-PA to operate in areas without causing or experiencing 
interference. In addition, WIA-PA is the only standard of the three that fully implements 
IEEE 802.15.4 [9]. This allows WIA-PA interoperability with other WSNs. The authors 
in [26] noted that WIA-PA’s use in ICSs is limited due to real-time constraints. They pro¬ 
posed a scheduling algorithm that utilized the centralized and decentralized communication 
allocation properties of the standard to achieve real-time requirements, thereby increasing 
the use cases of the standard. 

WIA-PA utilizes static routing by default. In [27], a dynamic source routing protocol called 
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WIA-PA Multi-path Dynamic Source Routing (WMDSR) was proposed. As noted in [9], 
source routing induces a higher latency as compared to static routes. Therefore, source 
routing was not adopted by the standard. 


2.4 Chapter Summary 

In this ehapter, we diseussed the existing researeh pertaining to WirelessHart, ISAlOO.l lA, 
and WIA-PA. We presented the limitations and challenges of each standard. We also 
diseussed the advantages of WIA-PA. 
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CHAPTER 3: 

WIA-PA System Model Implementation 


In the following sections of this chapter we discuss the IEEE 802.15.4 standard on which 
WIA-PA is based. We also discuss the ways in which WIA-PA uses and extends IEEE 
802.15.4. 

3.1 IEEE 802.15.4 

As was stated in Chapter 1, IEEE 802.15.4 defines the PHY and MAC layers of lower power 
devices. In the sections that follow, we describe the components of IEEE 802.15.4 that are 
implemented for our WIA-PA model. 

3.1.1 Components 

The IEEE 802.15.4 protocol defines two types of devices, a full function device (EED) and 
a reduced function device (RED) [7]. The EED refers to a device that has routing capability. 
An EED can act as a personal area network (PAN) coordinator, a coordinator, or a device 
within the network. An EED acting as a PAN coordinator has ownership of the network 
and allows other devices to join. If the EED is acting as a coordinator, it is routing traffic 
to and from devices and the PAN coordinator, but does not allow for devices to join the 
network. If the EED is set to operate in the device mode, it will only transmit data and does 
not have any routing functionality or joining capability. An RED is generally a sensor node 
that is providing data to the network. It does not have routing capability or ownership of 
the network. 

3.1.2 Topology 

Within an IEEE 802.15.4-enabled network, these EEDs and REDs can be combined to form 
either a star network topology or a peer-to-peer network topology [7]. The star topology 
is a one-hop network construct in which there is a single PAN coordinator and all other 
devices of the network can only communicate with the PAN coordinator. The next topology 
is peer-to-peer or mesh. In this network construct there is only one PAN coordinator but 
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multiple coordinators and each device in the network can communicate with any other 
device. This type of network is considered multi-hop, as the data can traverse multiple 
devices from source to destination. Examples of the star and peer-to-peer topologies are 
shown in Figure 3.1. 



Peer-to-Peer Topology 



# Full Function Device 
O Reduced Function Device 
^ Communication Flow 


Figure 3.1. Examples of Star and Peer-to-Peer Network Topologies. Source: 

[7]. 


A cluster-tree network topology is a combination of the star and peer-to-peer topologies 
and is the topology used in this thesis. In this construct there is one PAN coordinator and 
multiple coordinators. The coordinators form a peer-to-peer network. The devices connect 
to the coordinators to form the star topologies. Note that the coordinators can communicate 
with other coordinators in range. However, the devices can only communicate with their 
corresponding coordinator. An example of a cluster-tree network topology is shown in 
Figure 3.2. 

3.1.3 Physical Layer 

The physical layer of the IEEE 802.15.4 utilizes several operational frequencies bands with 
differing data rates [7]. Fisted in Table 3.1 are all available bands for IEEE 802.15.4 as well 
as the corresponding data rates and modulation schemes. The focus of this thesis will be on 
the 2.4 GHz frequency band. In this frequency band, 16 channels are available between 2.4 
and 2.4835 GHz with 5 MHz spacing. The physical layer is also responsible for the radio 
duty cycle (RDC) and clear channel assessment (CCA). This RDC turns the radio on and 
off and is important to meet the low power constraint of the sensor devices. The CCA is a 
process by which the physical layer determines if the channel is in use. 
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Figure 3.2. Example of a Cluster-Tree Network Topology. Source: [7]. 

PHY Protocol Data Unit 

The physical protocol data unit (PPDU) has a maximum size of 133 bytes. It includes 
a preamble, composed of 32 zeros, and an 8-bit start-of-frame-delimiter (SFD), which 
is defined as 11100101 [7]. The PPDU also contains the payload and a seven-bit field 
representing the length of the payload in bytes. The length field limits the PPDU a maximum 
payload of 127 bytes. The PPDU for IEEE 802.15.4 is presented in Figure 3.3. 



Octets 

1 

variable 

Preamble 

SFD 

Frame length 
(7 bits) 

Reserved 
(1 bit) 

PSDU 

SHR 

PHR 

PHY payload 


Figure 3.3. PPDU for IEEE 802.15.4. Source: [7]. 


3.1.4 Medium Access Control Layer 

The MAC layer is the interface between the physical layer of IEEE 802.15.4 and the higher 
layer protocols. It is responsible for managing beacons, accessing the channel, managing 
time slot allocation, as well as device association and disassociation [7]. The IEEE 802.15.4 
MAC layer supports two modes: beacon-enabled and non-beacon-enabled. In the beacon- 
enabled mode, the PAN transmits beacons to synchronize all attached devices and provide 
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Table 3.1. Frequency Bands and Data Rates for IEEE 802.15.4. Source: [7]. 


PHY 

(MHz) 

Frequency 

band 

(MHz) 

Spreading parameters 

Data parameters 

Chip rate 
(kchip/s) 

Modulation 

Bit rate 
(kb/s) 

Symbol rate 
(ksymbol/s) 

Symbols 

780 

779-787 

1000 

O-QPSK 

250 

62.5 

16-ary orthogonal 

780 

779-787 

1000 

MPSK 

250 

62.5 

16-ary orthogonal 

868/915 

868-868.6 

300 

BPSK 

20 

20 

Binary 

902-928 

600 

BPSK 

40 

40 

Binary 

868/915 

(optional) 

868-868.6 

400 

ASK 

250 

12.5 

20-bit PSSS 

902-928 

1600 

ASK 

250 

50 

5-bit PSSS 

868/915 

(optional) 

868-868.6 

400 

O-QPSK 

100 

25 

16-ary orthogonal 

902-928 

1000 

O-QPSK 

250 

62.5 

16-aty orthogonal 

950 

950-956 

— 

GFSK 

100 

100 

Binary 

950 

950-956 

300 

BPSK 

20 

20 

Binary 

2450 DSSS 

2400-2483.5 

2000 

O-QPSK 

250 

62.5 

16-ary orthogonal 

UWB 

sub-gigahertz 

(optional) 

250-750 

As 

defined in 
14.4.1 





2450 CSS 
(optional) 

2400-2483.5 

As 

defined in 
13.2 


250 

167 (as 
defined in 
13.4.2) 


As 

defined in 
13.2 


1000 

167 (as 
defined in 
13.4.2) 


UWB low 
band 
(optional) 

3244-4742 

As defined in 14.4.1 

UWB high 
band 
(optional) 

5944-10 234 

As defined in 14.4.1 


the structure of the superframe. The superframe structure is shown in Figure 3.4. The 
superframe provides the basis for communication within the PAN. 

The rate at which beacons are sent is the reciprocal of the beacon interval BI, is determined 
by the variable beacon order BO and can be changed to meet the demands of the PAN. 
Each coordinator, or FED, within the PAN will use the same BI. The BO is a value within 
the range 0< 50 <15. If the BO = 15, the PAN is operating in the non-beacon-enabled 


12 


























Beacons 


Ac 


:i /(; ocric 


a) Superframe without inactive period 
Beacons 


Ac 


t/e tone 


Inactive period 


b) Superframe with inactive period bme 

Figure 3.4. Superframe Structure for IEEE 802.15.4. Source: [7]. 


mode and will not transmit beacons regularly. Otherwise, 

BI = aBaseSuper frame Duration ■ 2®^, (3.1) 

where aBaseSuper frameDuration is defined as 
aBaseSuperframeDuration = aNumSuperframeSlots ■ aBaseSlotDuration (3.2) 

with aBaseSlotDuration = 60 symbols/slot and aNumSuper frame Slots = 16 slots. 

The BO establishes the frequency of the beacon interval, but the duration of the active period 
is governed by the superframe order 50. This value is within the range 0 < SO < BO < 15. 
If the SO = 15, then BO = 15 and the PAN is operating in the non-beacon-enabled mode. 
For the superframe to contain an inactive period, SO < BO. An example of the superframe 
inactive period is shown in Figure 3.4b. The superframe duration, SD, is calculated as 

SD = aBaseSuper frameDuration ■ 2^^. (3.3) 


The active period of the superframe is divided into 16 time slots of equal duration. These 
time slots are grouped into a contention access period (CAP) and a contention free period 
(CFP). During the CAP, if a device needs to transmit it must use the slotted variant of 
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carrier sense multiple access with collision avoidance (CSMA/CA) prior to transmission. 
CSMA/CA is described in further detail in Section 3.1.5. 

Devices requiring a guaranteed quality of service (QoS) are assigned a guaranteed time 
slot (GTS) during the CFP. This means that a specific timeslot has been allocated to a 
specific device similar to a TDM A construct. The CAP is shortened by the amount of the 
CFP so that both periods are contained within the active portion of the superframe. The 
inactive period of the superframe allows devices to sleep, meaning that a device has the 
ability to turn off its radio with the assumption that no communications will occur during 
this period. As mentioned previously, the IEEE 802.15.4 non-beacon-mode does not send 
beacons regularly and all devices desiring to transmit must contend for the channel using 
the unslotted CSMA/CA without the option of a GTS. The slotted variant of CSMA/CA 
will be the focus of this thesis. 

MAC Protocol Data Unit 

The MAC protocol data unit (MPDU) sets the structure for the MAC frame. The general 
MAC frame construct is shown in Figure 3.5. 
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Figure 3.5. General MAC Frame Structure. Source: [7]. 


Each frame uses the frame control field to identify how the frame is constructed [7]. The 
details of the frame control field can be seen in Figure 3.6. The frame type field identifies 
which frame is being transmitted: beacon, data, acknowledgement, or command. The 
security enabled field indicates whether or not the PAN is operating with encryption. The 
frame pending field is used by a coordinator to signal that data is pending for a node within 
its cluster. The PAN ID compression field is a one-bit field that allows for the omission of 
one of the two PAN identifier fields in the MAC frame, if the two fields are the same. The 
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addressing modes are two-bit fields that identify whether the eorresponding address field is 
present, and if it eontains the 16-bit or 64-bit address. 
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Figure 3.6. Frame Control Field Structure. Source: [7]. 


IEEE 802.15.4 defines four MAC frame types: beaeon, aeknowledgement, data, and eom- 
mand. The beaeon frame shown in Eigure 3.7 is used to synehronize the deviees in the 
PAN and to provide the strueture of the superframe. The MAC payload of the beaeon 
frame eontains the superframe speeifieations, shown in Eigure 3.8. The deviees within the 
PAN extraet the superframe speeifieations to determine the aetive and inactive portions, as 
discussed in Section 3.1.4. 
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Figure 3.7. Beacon Frame. Source: [7]. 


Embedded within the superframe specification is the BO, SO, the timeslot in which the 
CAP ends and whether or not the beacon received is from the PAN coordinator. 
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Figure 3.8. Superframe Specification. Source: [7]. 


Acknowledgement frames within IEEE 802.15.4 are only transmitted after receipt of data or 
command frames and if the acknowledgement request field is set in the frame control field. 
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Octets: 2 
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Frame Control 
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Figure 3.9. Acknowledgement Frame. Source: [7]. 


The acknowledgement frame shown in Figure 3.9, contains no addressing information and 
only identifies the frame sequence number to which it is in response. 


The command frame structure can be seen in Figure 3.10. These frames are used for control 
of the PAN, to include device joining, association, disassociation, and for devices to request 
pending data from the coordinator. 
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Figure 3.10. Command Frame. Source: [7]. 


The data frames are used to communicate all other data not related to coordination and 
control of the PAN. The data frame structure is shown in Figure 3.11. 
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Figure 3.11. Data Frame. Source: [7]. 


3.1.5 Functional Overview 

Data Transfer 

There are three data transfer concepts in IEEE 802.15.4 [7]. Data can be transmitted from a 
coordinator, to a coordinator, and peer-to-peer. When a coordinator needs to transmit data to 
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a connected device and is operating within a beacon-enabled PAN, it will utilize the beacon 
to signal that it has data and indicate the device for which the data is intended. If the PAN 
is non-beacon-enabled, the coordinator will hold the data until the intended device submits 
a request for the data. When data is transferred to a coordinator in the beacon-enabled 
mode, the device must synchronize to the beacon frame and transmit when appropriate. In 
a non-beacon-enabled PAN, the device utilizes unslotted CSMA/CA to transmit the data. 
For data to be transferred among peers, the devices transmit directly to all other devices 
within its radio transmit range. This requires each device to either listen continuously or 
synchronize with each peer to ensure receipt of transmission. 

CSMA/CA 

CSMA/CA is a carrier sensing protocol, by which a device wanting to transmit waits a 
random amount of time (called a backoff period), senses the channel to determine if it is 
available, and then transmits when able [7]. The algorithm implemented for CSMA/CA is 
represented in Appendix A. CSMA/CA can be utilized in one of either two modes, slotted 
or unslotted. When the unslotted mode of CSMA/CA is used, the backoff period of each 
device is unrelated to any other device. In the slotted mode, the backoff period boundaries 
are aligned to the timeslots of the superframe for each device. 

3.2 WIA-PA 

As previously discussed, WIA-PA is based on and extends the IEEE 802.15.4 standard. The 
following sections describe how WIA-PA does this. 

3.2.1 Components 

WIA-PA maintains the IEEE 802.15.4 definitions of EED and RED, but renames the devices 
based on roles [28]. The standard identifies five devices: host configuration computer, 
gateway, routing device, field device, and handheld device. The purpose of the host 
configuration computer is to set the parameters for all of the superframes within the network, 
provide resources when devices initiate a join request, assign communication resources to 
the routing devices, and create and disseminate all routing tables within the network. The 
gateway and routing devices are the same as the EED in IEEE 802.15.4 and provide the 


17 



network connectivity and routing. The field devices are sensors and the handheld devices 
are remote network management or user access points. 

3.2.2 Topology 

The topology that WIA-PA utilizes is a combination peer-to-peer and star [28]. The routing 
devices communicate with each other in a peer-to-peer topology, with each routing device 
able to head its own star. An example of this network topology is shown in Figure 3.12. 
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Figure 3.12. Example of a WIA-PA Network Topology. Source: [28]. 


3.2.3 Physical Layer 

WIA-PA only allows the 2.4 GHz frequency band and a data rate of 250 kbps [28]. IEEE 
802.15.4 defines channels 11 - 26 to frequencies 2,405 MHz to 2,480 MHz, with 5 MHz 
spacing [7]. WIA-PA does not support channel 26, as defined in IEEE 802.15.4, as it is not 
universally compliant [28]. 
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3.2.4 Medium Access Control Layer 

The MAC layer specification in WIA-PA utili z es the beacon-enabled mode of IEEE 802.15.4 
and the BI is defined as in (3.1) [28]. The active portion of the WIA-PA superframe is 
divided into the CAP and the CEP. The CAP is only utilized for device joining and 
association and management of the PAN. CSMA/CA is utilized during this period for 
communication. Upon completion of the CAP, all other communications occur during 
assigned timeslots. The CEP is designated for communication between the cluster head 
and handheld devices. WIA-PA extends the IEEE 802.15.4 superframe and utilizes the 
inactive portion for intra- and inter-cluster communication as well as device sleeping. As 
the WIA-PA superframe includes the inactive portion, the base superframe duration is 
calculated by setting the aNumSuper frame Slots to 32 in (3.2). 

WIA-PA allows for multiple superframes across the PAN, however each routing device and 
RED is only associated with one superframe at a time [28]. Each superframe can be made 
up of a different number of timeslots, but the timeslot duration will be constant across the 
PAN. This is configured by the host configuration computer based on the requirements of 
the devices within a given cluster. The short address of devices joining the network are also 
assigned by the host configuration computer. The short address is 16 bits long, where the 
most significant eight bits designate the cluster and the least significant eight bits identify 
the device within the cluster. 

3.2.5 MAC Protocol Data Unit 

The MPDU has some differences from that of IEEE 802.15.4. Within the frame control 
field, the security field is always zero and the PAN ID compression flag is always set to 
one [28]. This means that communication is not allowed between PANs. After a device 
joins, it must utilize its short address to communicate. WIA-PA does not utilize the GTS 
of IEEE 802.15.4. Instead, the network layer assigns links and communication resources to 
devices based on the update rate of the device. The link information includes a timeslot, a 
channel, and type of communication, which is either transmit, receive, or share. 

The MAC layer is also responsible for synchronizing devices upon joining the network. 
This occurs via the beacon frame. WIA-PA adds a payload to the beacon that includes the 
cluster ID with which the beacon is associated, the absolute slot number, a timer value, and 
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the channel on which the next beacon will be transmitted [28]. The absolute slot number is a 
timeslot counter that is incremented by one for each timeslot. The timer value is the elapsed 
time from the transmission of the beacon to the beginning of the timeslot. Before a device 
joins the network, it passively scans for beacons and synchronizes with the information in 
the beacon payload. This synchronization does not have enough fidelity to meet real-time 
requirements so the routing devices will also transmit synchronization command frames. 

3.3 Chapter Summary 

In this chapter, we discussed the IEEE 802.15.4 standard and the ways in which WIA-PA 
uses and extends the standard. The discussion of this chapter provides the foundation for 
our MATEAB implementation of WIA-PA. 
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CHAPTER 4: 
Results and Analysis 


In this chapter we present our experimental design and system model used in the simulations. 
We also discuss the various components of the WIA-PA standard that are implemented for 
this thesis. The performance metrics that we evaluated on the WIA-PA model are as follows: 

• end-to-end delay: the delay incurred from the time a packet is transmitted by a node 
to when it is reached by the gateway 

• received packet error rate: the number of packets received in error by the gateway 
calculated as a percentage of total packets transmitted 

• timeslot utilization: a measure of how well WIA-PA nodes maximize timeslot use 


4.1 Experimental Design 

Initialization 

The system model includes two MATLAB class definitions: wia_ffd.m (Appendix B.1.1) 
and wia_rfd.m (Appendix B.1.2). These classes form the template for the devices and 
allocate properties necessary for the devices to operate in the network. For example, the 
classes create buffers rx and tx, which are buffers to hold data that either a device received 
or will transmit. Other properties that are created, such as clusterjd, m y_short_address, 
and bcn_payload, provide allocated resources for the device to store data from commu¬ 
nications it receives from the network. The cluster_id identifies the cluster to which a 
device is connected and also serves as the first two octets of the device’s short address once 
associated. The short address of a device is stored in the m y_short_address property. 

The beacons that are transmitted by FFDs contain payload information that is important for 
network synchronization [28]. This information is stored in the bcn_payload property. 
When a device is initialized, certain properties are set depending on the type of device 
desired. For example, when an FFD is initialized as a PAN coordinator, the associated 
parameter, the m y_short_address property, and information required for beacon structure 
are set. The other FFDs and RFDs are initialized without this information and will obtain 
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the appropriate property values during the assoeiation proeess. Along with alloeating these 
properties, these elasses build timers to allow for the deviee funetions. The MATLAB timer 
elass was utilized to allow for pseudo multi-threading eapability. The timers themselves 
will run as an individual proeess, but the funetions that the timers exeeute are seheduled 
to the proeessor serially. These timers allow the deviee to send data or eheek the status 
of properties on a given interval. The main differenee between the two elass definitions 
is that the wia_ffd elass uses a beaeon timer, while the wia_rfd elass uses a data timer. 
In our model, we are not eonsidering the FFD as sending its own data, even though it is 
able to. The RFDs, however, do not transmit beaeons and, therefore, do not have a beaeon 
timer [28]. The flow ehart deseribing deviee initialization is shown in Figure 4.1. 



Figure 4.1. Device Initialization Flow Graph 
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Association 

When a device (that is not the PAN coordinator) is initialized, it is not associated to the 
PAN. The device begins listening for beacons. Once a beacon is received, the device will 
transmit an association request command frame within the CAP. Once the PAN coordinator 
receives the association request, from one or multiple devices, it will set the framepending 
flag in the beacon and append the intended addresses in the beacon payload. After receiving 
the next beacon, each device listed in the payload will send a data request to poll for the 
pending data. The PAN coordinator will then provide the device with a short address for 
the network [28]. 

If the associating device is a routing device, its address will be AAGO where A A is a 
hexadecimal representation of the cluster ID [28]. If the device is an RFD, its address will 
be XXYY, where XX is the cluster ID and YY is the host identification within the cluster. 
Once a routing device is associated, it will begin transmitting its own beacons to devices 
within its transmission range. The PAN coordinator has to provide the association response. 
For a node two or more hops away, the parent must forward the association request to the 
PAN coordinator and forward the response back to the node. No device is able to send data 
on the network until it is associated. Once associated, the node sends data to its parent, 
which forwards data to the gateway. An example of the association flow can be seen in 
Figure 4.2 [28]. 



Data Transfer 

To allow for the simulation of data transfer, we build neighbor tables to simulate the radio 
transmission range of the devices. These neighbor tables are created after all the devices are 
initialized, but before the timers are started. When a device wishes to communicate, it calls 
the transmit function (Appendix B.2.28). This is the function that fully creates the PPDU 
that will be transmitted. Within the function is a call to have the MPDU created (Appendix 
B.2.12). When the MPDU is returned to the transmit function, the rest of the PPDU header 
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is added and a call to the channel (Appendix B.2.8) function is made. The transmit function 
then adds the packet to a send buffer. Each device has a send timer that polls this buffer and 
determines when a packet is available for transmission. If the packet is a data frame, the 
packet will be scheduled to be added to the channel during the appropriate timeslot, while 
a command frame will need to be transmitted during a CAP [28]. The channel function 
copies the data to be transmitted into the channel buffer of each device within its neighbor 
table. To simulate data propagation within the channel, we delay copying the data to the 
channel buffer by the amount of time calculated as 


Delay = 


length(PPDU) 

Rb 


(4.1) 


where Rb is the bit rate of 250 kbps [28]. A depiction of how the transmit function operates 
can be seen in Figure 4.3. 



Figure 4.3. Transmit Flow Graph 


Each device also polls its receive buffer, utilizing the parse timer to see if data is available. 
When data is found, the devices immediately parse the packet to build the required informa¬ 
tion for the superframe. The parse timer calls the parse function (Appendix B.2.19), which 
simply removes the first item from a received frame buffer, calls the parsejwia function, 
and fills the rx buffer as the data is parsed. Once the received packet has been parsed, 
the parsed function is called. The parsed function determines how the device responds 
depending on how its parameters are currently set. For example, after a device receives a 
beacon, it is the parsed function that checks to see if the device is associated or whether it 


24 








is an FFD. It then initiates the appropriate response. The parse timer eontinuously eheeks 
the state of the reeeive buffer. A simple flow ehart depieting the use of this timer is shown 
in Figure 4.4. 



Figure 4.4. Parse Timer Flow Graph 


4.2 Simulation Model 

WIA-PA allows for the number of timeslots within a superframe to be set by the user [28]. 
For simplifieation, we ehose to use a superframe eonsisting of 32, 10-ms timeslots. We 
divided the 32 timeslots equally among the four periods of the superframe: CAP, CFP, 
intra-eluster period, and inter-eluster period. We ignored a dedieated sleep period aeross 
the network. Within the inter-eluster period, we required the eluster heads to share a single 
ehannel. WIA-PA allows for multiple ehannel use, but utilizing multiple ehannels reduees 
the problem to a single eluster seenario [28]. We ehose to utilize only a single ehannel 
within the inter-eluster period to expand our testbed. By using the single ehannel during 
the inter-eluster period, we are limited to eight timeslots for eaeh period of the superframe, 
whieh restriets our network size to a total of eight nodes. The number of nodes is determined 
by the number of timeslots available in the inter-eluster period. Sinee there are only eight 
timeslots, the eluster heads are only able to forward data to the gateway for eight nodes. 

Next, we assumed that eaeh deviee has sueeessfully joined the network, in aeeordanee 
with [28]. Our model does not simulate the joining proeess beeause we were not able to use 
multiple proeessing threads in our MATLAB implementation. The utilization of multiple 
proeess threads allows for proeesses to be seheduled in parallel. Without using multiple 
proeessing threads, eaeh proeess is seheduled serially on the eentral proeessing unit (CPU) 
instead of in parallel. 

During the joining proeess, a node is alloeated a short address and a timeslot for data 
eommunieation [28]. The timeslot alloeated to eaeh node, within the intra-eluster period, 
eorresponds to the node’s short address. For example, the node with short address 0101 is 
the first node of eluster 01. It will transmit at the start of the first timeslot of the intra-eluster 


25 






period, or timeslot 16 within the superframe [28]. The cluster heads transmit in order of 
cluster number and use the number of slots equal to the number of child nodes. Cluster head 
0100 with three nodes would then transmit for the first three timeslots of the inter-cluster 
period, or timeslots 24 to 26. We implemented this scheduling method, since a scheduling 
method is not defined in [28]. 

Another assumption that we made is that data is transmitted only from the node to the 
gateway. During the delay and received packet error rate simulations, we did not include 
acknowledgement frames, since acknowledgement frames are not required [28]. Acknowl¬ 
edgement frames were, however, considered during the timeslot utilization calculations. 

As discussed previously, our implementation does not utilize multiple process threads. 
MATLAB is only able to schedule processes at intervals of 1 ms, but implementing this 
becomes too computationally intensive and other process do not get scheduled. Due to 
this, we expanded our simulation time to be in terms of seconds, and scaled data rates and 
processing rates to match. For simulation purposes, our timeslot within the superframe 
is one second and the data rate is 2.5 kbps, as compared to the 10 ms and 250 kbps 
intended [28]. 

4.3 End-to-End Delay 

In this section we measure the time required for a gateway to receive data from a node 
within the network. We look at three situations: a single cluster containing a single node, a 
single cluster containing eight nodes, and two clusters containing four nodes per cluster. 

4.3.1 Single Cluster Containing Single Node 

In the case of a single cluster containing a single node, the theoretical delay tdelay is defined 
as 

tdelay — ttrans tprop (4.2) 

where ttrans is how long it takes for the device to physically send the data, tprop is how long 
the data takes to propagate through the channel (based on a distance of 10 m [7]), and %tsiot 
is the duration between the node’s allocated timeslot and that of the cluster head [28]. Based 
on the parameters of our model and with a frame size of 176 bits, tdelay equates to 8.07 ms. 
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We observed an average end-to-end delay of approximately 8.083 ms from 1000 transmitted 
data frames. The measured delay shows a .16% increase over the expected delay, which is 
believed to be caused by variances in the MATLAB implementation. 

4.3.2 Single Cluster Containing Eight Nodes 

Our next simulation increased the cluster size. The delay equation (4.2), applies to all nodes 
within the cluster. With this, we expected to see a delay of 8.07 ms, as in the single node 
case. The average delay that we observed in this case was 8.125 ms. This delay is a .52% 
increase over the expected value from the single node case. We believe that the increased 
delay is due to computational resources in MATLAB. The delay grows incrementally as the 
number of nodes grows. However, in this scenario, the number of nodes should not affect 
the delay of any other node. 

4.3.3 Two Clusters Containing Eight Nodes Total 

For our third simulation, we increased the number of clusters, and included four nodes in 
each cluster. In this case, the expected delay is the 8.07 ms for the nodes in the first cluster, 
but the second cluster has an additional delay of ^tsiot, as seen in 

^delay ~ ^trans ^prop "I" slot "I" ^^slot- (4.3) 

This additional delay is incurred because the gateway allocates cluster heads with timeslots 
within the inter-cluster period based on the number of nodes within each respective cluster 
[28]. Since the first cluster contains four nodes, the added delay for the second cluster is 
4tsiot, and the expected delay for the nodes within the second cluster is 12.07 ms. Here, 
again, we observed an increase in delay as the complexity of the network increased. We 
observed an 8.234 ms delay for the first cluster and a 12.335 ms delay for the second. The 
results confirm the expected increase of the delay in the second cluster, but is higher than 
expected. This result is again believed to be due to resource constraints within MATLAB. 

WIA-PA, WirelessHart, and ISAlOO.llA utilize TDMA for data communication within 
allocated timeslots [9]. While WirelessHart and ISAlOO.llA mainly implement a mesh- 
network configuration and our model of WIA-PA implements a mesh-star topology, the 
analysis of the delay in each network reduces to analyzing the delay within individual 
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timeslots over the number of hops between the node and the gateway. Since WirelessHart 
and ISAlOO.llA utilize graph-based routing, the delay equation becomes 

tdelay ~ ^trails "I” tprop ^ slot (4.4) 

for the single node case [9]. As the number of routing devices and nodes increase in a 
WirelessHart and ISAlOO.llA network, the delay also grows, but is determined by the 
routing algorithm and the order in which the devices are scheduled to transmit. 

Within our model, the results from the end-to-end delay of the single cluster with a sin¬ 
gle node shows that there is a It slot greater delay in WIA-PA. As the complexity of the 
network topology grows, the delay is deterministic based on the number of nodes in the 
network. However, the delay in WirelessHart-enabled and ISAlOO.llA-enabled networks 
is dependent upon the routing algorithm and when nodes are scheduled to transmit [9]. 

4.4 Received Packet Error Rate 

Another key aspect of WIA-PA performance is the received packet error rate. To measure 
this rate, we count the number of data packets transmitted by a node and the number of 
packets correctly received by the gateway over a 24-hour period. We then calculate the 
percentage received by the gateway in error. We test the same three scenarios as in Sections 
4.3.1-4.3.3. 

4.4.1 Single Cluster Containing Single Node 

During this scenario, a single node transmitted a packet every second, which led to 86,400 
data frames transmitted during the 24-hour period. The gateway correctly received all 
86,400 data frames, resulting in a 0% received packet error rate for this simulation. 

4.4.2 Single Cluster Containing Eight Nodes 

This simulation consisted of 691,200 data frames transmitted equally across the eight nodes 
within the same cluster. This time the gateway only received and correctly parsed 669,376 
data frames. This simulation yielded an error rate of 3.16% for our model. This scenario 
simulates only one cluster, and each node within the cluster is allocated its own timeslot. We 
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expected to see the same results as in the simulation with only a single cluster and a single 
node. The increase in error from this simulation is believed to be due to MATLAB. As 
with the end-to-end delay results presented in Sections 4.3.1-4.3.3, the increase in number 
of nodes of the cluster also increases resource requirements in MATLAB and leads to 
increased error rates. 

4.4.3 Two Clusters Containing Eight Nodes Total 

This simulation consisted of 691,200 data frames transmitted equally across the eight nodes, 
but this time the nodes are separated into two different clusters. During this simulation, the 
gateway correctly parsed only 620,237 data frames. This resulted in an error rate of 10.27% 
for our model. Aside from the increase in theoretical delay, this simulation should also 
reduce to the single cluster with a single node case. The increase in incorrectly received 
packets is due to resource constraints within MATLAB as the complexity of the network 
increases. 


4.5 Link Utilization 

IEEE 802.15.4 allows for data to be transmitted utilizing either CSMA (during the CAP) or 
TDMA (within a GTS) [7]. Devices, based solely on IEEE 802.15.4, must request a GTS 
when a deterministic delay is desired. Therefore, there are two types of link utilization: 
contention based and link. WIA-PA, however, uses the CAP only for network management 
and TDMA for all data communication [28]. Similarly, WirelessHart and ISAlOO.llA 
use TDMA for data transmission for deterministic delay [9]. Link utilization within a 
WIA-PA enabled network, and an IEEE 802.15.4 GTS, is essentially a measure of timeslot 
utilization. This is due to the fact that WIA-PA nodes only transmit data during allocated 
timeslots [28]. To ensure maximum timeslot link utilization, the timeslot duration must 
equal the propagation duration of the data frame, when acknowledgement frames are not 
required. The timeslot duration tts is defined by 

SmaxPPDU ,, _ 


where maxPPDU is 133 bytes (as described in Section 3.1.3), and Rb is the bit rate of 250 
kbps [7]. 


29 



Using 



where PPDUack is 11 bytes long [7]. Using (4.6) and (4.7), we find that 4.608 ms is the 
minimum tfs timeslot duration required to maximize the timeslot utilization when including 
acknowledgement frames. 

In our model, the tts is 10 ms and the PPDU is 22 bytes long. Using (4.6), we find that 
timeslot utilization of our model is 7.04%. If we utilized a frame with maximum data 
length, our timeslot utilization increases to 42.56% [7]. If we require acknowledgement 
frames as well, we see that our timeslot utilization increases to 46.08%. 

While the model’s timeslot utilization is low, the battery life of the node is extended. This 
is because the node is in a sleep state when not transmitting during a timeslot [28]. The 
lower the tts, the shorter the superframe duration, and therefore the more often the node is 
active and not sleeping. The power efficiency can be improved by increasing the tts, thereby 
increasing the amount of time the device is in a sleep state [29]. Also, the timeslot utilization 
determined in our model is the same as the timeslot utilization found in a WirelessHart or 
an ISA 100.11 A network since they also use the IEEE 802.15.4 data link layer standard [9]. 
WirelessHart requires a 10 ms timeslot, thus the timeslot utilization would be exactly the 
same as that of WIA-PA [9]. The timeslot duration within an ISAlOO.llA network is 
configurable, but the utilization would also be the same provided a timeslot duration of 10 
ms is used [9]. 
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4.6 Chapter Summary 

In this chapter, we compared the end-to-end delay of our model with the theoretical delay 
based on the WIA-PA standard. Our results indicate that the end-to-end delay of our model 
is consistent with the theoretical values in the simplest case. Our end-to-end delay results 
are also similar to the expected delays in WirelessHart and ISAlOO.llA networks [9]. 
However, as the number of nodes in our model is increased, the delay also increases. This 
increase is not due to the WIA-PA standard, but instead due to the computational expense 
in MATLAB. We also measured the received packet error rate for our model during a 
24-hour period for three different situations. This error rate increased as we increased the 
number of nodes and complexity of the model. As with the measured delay, we believe 
that the rate of increase of the received packet error rate, between the different scenarios, 
is influenced by the computational expense of the model’s complexity within MATLAB. 
Finally, we calculated the minimum timeslot duration to maximize the timeslot utilization. 
We determined that the timeslot utilization for our model is less than 50%, which leads to 
an increase in sleep duration of the nodes when compared to a higher timeslot utilization. 
This timeslot utilization is the same as expected in a WirelessHart network, as well as in an 
ISAlOO.l lA network configured to use a timeslot with a duration of 10 ms [7]. 
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CHAPTER 5: 

Conclusions and Future Work Recommendations 


5.1 Summary and Conclusions 

An ICS is a vital asset to the DOD. The addition of WSNs to an ICS has facilitated 
greater automation and network scalability. WIA-PA, WirelessHart, and ISAlOO.llA are 
all wireless standards that can be used in an ICS. However, the advantages of WIA-PA over 
WirelessHart and ISA 100.1 lA make this standard a viable option for expanded use outside 
of China. To establish a performance base for this standard, we built a custom model in 
MATLAB. We have shown that our model provides end-to-end delay results comparable 
to the theoretical delay based on the WIA-PA standard, and confirms the deterministic 
capacity for data transmission of the WIA-PA standard. We also measured the error rate of 
our model. For the simple case, we observed no error between the number of data packets 
transmitted by the node and the number received by the gateway. As the number of nodes 
and complexity of the model was increased, however, we observed an increase in the error 
rate. Finally, we calculated the timeslot utilization of our model. We determined that our 
model maintained a very low timeslot utilization. 

We expect WIA-PA to perform as well as WirelessHart and ISAlOO.llA with the added 
advantage of being able to coexist with other beacon-enabled networks. In the simplest 
scenario of our model, the measured results should be the same as expected in the other 
network implementations. The discrepancies we found in our simulations are believed to 
be due to the simulation environment, and not because of the WIA-PA implementation. 

5.2 Future Work 

In this thesis, we demonstrated that WIA-PA performs effectively in multiple network 
scenarios. However, there are areas of follow on research that would facilitate further 
analysis of the standard. 
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5.2.1 Network Simulator 

MATLAB is not suited to efficiently simulate networks with network traffic. The imple¬ 
mentation of WlA-PA using a network simulator, such as Contiki or the NS family, would 
make it more robust and provide more opportunities for in-depth analysis. 

5.2.2 Validation of Security 

The security of WlA-PA has not been characterized and the standard has not been subjected 
to various forms of attacks. A thorough security analysis needs to be undertaken to assess 
the standard’s vulnerability and exploitability. 

5.2.3 Routing 

WlA-PA currently only supports static routing. By extending the standard to incorporate a 
dynamic routing protocol, such as Routing Protocol for Low-Power Lossy Networks (RPL), 
WlA-PA can be made more robust and instill self-healing capabilities. 
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APPENDIX A: 
CSMA/CA 
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Figure A.l. CSMA/CA Algorithm. Source: [7]. 
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APPENDIX B: 
MATLAB Code 


B.l Classes 

B.1.1 wia ffd.m 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 
27 


% wia_ffd.in in the @wia_ffd folder 

% This is the class definition for Full Funciton Device (FFD) 

classdef wia_ffd < handle 
properties 
name; 
my_c i; 
wia_cmd; 
pan_coord = 0; 
pan_coord_add = 0; 
parent_add = 0; 
cluster_id = '00'; 
pan_id; 
assoc = 0; 
my_long_address; 
my_short_address = 'ffff; 
next_rt_address = '01'; 
next_leaf_address = {{0}}; 


rx = struct{ 

'fcf, [ 

] , 'sf. 

[], 'P', 

[], 'ci'. 

[] , 

payload' , 

tx = struct{ 

[]); 

'fcf, [ 

] , 'sf. 

[], 'P', 

[], 'ci'. 

[] , 


payload' , []); 

bcn_payload; 
tx_frame=[]; 
rx_frame=[]; 
rec_f rame=[]; 
state=l; 
lock = 0; 
bcn_frame=[]; 
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28 last_seq_num = 0; 

29 d_seq_num = 0; 

30 b_seq_num = 0; 

31 ack_table = []; 

32 beacon_t; 

33 cc_t; 

34 send_t; 

35 asn_t; 

36 parse_t; 

37 p_t; 

38 assoc_t; 

39 rsn_t; 

40 bcn_tiinestamp; 

41 payload = strrep (num2str (ones (1,40) ) , ' 

42 chan= ' ' ; 

43 n_table={}; 

44 waiting = 0; 

45 join_table= { { } }; 

46 send_buf = { } ; 

47 send_data_buf = { }; 

48 direct = ' ' ; 

49 buffer = {}; 

50 i; 

51 pend_add = { } ; 

52 asn_start = 0; 

53 rsn=0; 

54 alloc; 

55 

56 count = 0; 

57 

58 end 

59 methods 

60 function set_name (ob j , num) 

61 obj.name = strcat { ' f fd_' , num2str (num) ) ; 

62 end 

63 

64 function set_pan_coord (ob j ) 

65 ob j .pan_coord = 1; 

66 ob j .my_short_address = '0000'; 

67 obj.pan_coord_add = obj.my_short_address; 
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68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 
87 


89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 


obj.assoc = 1; 
obj.asn_start = 0; 

end 

function set_long_add{obj, add) 

obj.my_long_address = strcat ('ffffffff, dec2hex(add, 8) 

); 

end 

function set_pan_id(obj, id) 
if obj.pan_coord 

obj.pan_id = id; 

else 

disp{'not pan_coord') 
return 

end 

end 

function struct_init(obj) 
load( 'wia_structs.mat' ); 


obj.rx=struct( 'fcf' , fcf, 

, ci, 'payload' , []); 

'sf' , 

superframe. 

'P\ 

P, 

' ci 

obj.tx=struct( 'fcf' , fcf, 

, ci, 'payload' , [ ] ) ; 

'sf' , 

superframe. 

'P\ 

P, 

' ci 


obj.bcn_payload = bp; 
obj.my_ci = ci; 
obj.wia_cmd = wia_cmd; 
clear fcf sf p ci bp wia_cmd 

end 

function set_val(obj) 

obj.my_ci.dev_type = 0; 
obj.my_ci.power_src = 1; 
obj.my_ci.rec_idle = 0; 
obj.my_ci.sec_cap = 0; 
obj.my_ci.allocate_add = 1; 

obj.tx.sf.BO = 3; 
obj.tx.sf.SO = obj.tx.sf.BO; 
obj.tx.sf.finCapslot = 15; 
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105 


1 ; 


obj.tx.sf.pan_coord = 

lOS 

107 ob j . tx . f cf . ack;_req = 1; 

108 ob j . tx . f cf . dest_mode = 2; 

109 ob j . tx . f cf . src_mode = 2; 

110 

111 ob j . tx . p . src_pan_id = obj.pan_id; 

112 ob j . tx . p. dest_pan_id = obj.pan_id; 

113 ob j . tx . p . src_add = ob j .my_short_address; 

114 end 

115 

116 function initialize (obj ) 

117 global ts 

118 struct_init (ob j ) ; 

119 set_val (obj ) ; 

120 delay = 0; 

121 name = strcat (obj .name, '_beacon'); 

122 obj.beacon_t = timer (' Name name, ' TimerFcn @ (-i,-i) beacon 

(obj), 'StartDelay ', delay, 'ExecutionMode' , 'fixedRate' , 
'Period' ,32*ts); 

123 name = strcat (obj . name, '_asn'); 

124 obj.asn_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) inc_asn ( . 

obj) , 'BusyMode' , 'queue' , 'ExecutionMode' , 'fixedRate' , 

'Period' ,ts); 

125 name = strcat (obj . name, '_send'); 

126 obj.send_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) send (obj 

), 'BusyMode' , 'drop' , 'ExecutionMode' , 'fixedRate 

Period' ,ts/4); 

127 name = strcat (obj . name, '_parse'); 

128 obj.parse_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) parse ( . 

ob j) , ' ExecutionMode ' , 'f ixedRate ' , ' BusyMode ' , ' drop ' , ' . 
Period' ,ts/10); 

129 name = strcat (obj . name, '_p'); 

130 obj.p_t = timer (' Name ', name, ' TimerFcn ', @ (- 1 ,-i) parse_wia ( . 

obj), 'ExecutionMode' , 'singleshot' ); 

131 name = strcat (obj . name, '_assoc'); 

132 obj.assoc_t = timer (' Name ', name, ' TimerFcn ', @ (- 1 ,-i) .. . 

assoc_func(obj), 'ExecutionMode' , 'fixedRate' , 'Period' 

, ts/5); 

133 name = strcat (obj . name, '_rsn'); 
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135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 end 


obj.rsn_t = timer {' Name name, ' TimerFcn ', @ inc_rsn ( . 

obj) , 'ExecutionMode' , 'fixedRate' , 'StartDelay 

Period' , ts); 

end 

function prop = get_prop(obj, property) 
prop = obj. (property); 

end 

function set_prop(obj, property, value) 
obj.(property) = value; 

end 

function start(obj) 
if obj.pan_coord 
asn_timer(); 
beacon_timer(obj) ; 
parse_timer(obj) ; 
send_timer(obj) ; 
elseif -lOb j . pan_coord 
assoc_timer(obj) ; 
parse_timer(obj) ; 
send_timer(obj) 

end 

end 


end 


B.1.2 wia rfd.m 


1 % wia_rfd.m in the @wia_rfd folder 

2 % This is the class definition for Reduced Funciton Device (RED) 

3 

4 classdef wia_rfd < handle 

5 properties 

6 name; 

7 my_ci; 

8 wia_cmd; 
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9 pan_coord = 0; 

10 pan_id; 

11 pan_coord_add; 

12 parent_add; 

13 assoc = 0; 

14 my_long_address; 

15 my_short_address = 'ffff; 

16 rx; 

17 tx; 

18 bcn_payload; 

19 tx_fraine = []; 

20 rx_fraine = []; 

21 rec_frame= [ ' ' ] ; 

22 state=l; 

23 lock = 0; 

24 ack_table = []; 

25 last_seq_num; 

26 d_seq_num = 0; 

27 cc_t; 

28 rsn_t; 

29 assoc_t; 

30 parse_t; 

31 send_t; 

32 data_t 

33 p_t ; 

34 bcn_timestamp = tic; 

35 payload = strrep (num2str (ones (1 ,40) ) , ' 

36 waiting = 0; 

37 chan= ' ' ; 

38 n_table= { { } }; 

39 direct = ' ' ; 

40 buffer = {}; 

41 cluster_id; 

42 asn_start = 0; 

43 send_buf = { } ; 

44 send_data_buf = { }; 

45 rsn = 0; 

46 alloc; 

47 count = 0; 

48 end 
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49 methods 

50 function set_name (ob j , num) 


51 

obj.name = strcat (' rfd_' ,num2str(num)); 



52 

end 



53 




54 

function struct_init(obj) 



55 

load( 'wia_structs.mat' ); 



56 

obj.rx = struct (' fcf' , fcf, 'sf, superframe. 

'P\ 

p, ' ci 


' , ci, 'payload' , []); 



57 

obj.tx = struct (' fcf' , fcf, 'sf, superframe. 

'P\ 

p, ' ci 


' , ci, 'payload' , []); 



58 

obj.wia_cmd = wia_cmd; 



59 

obj.bcn_payload = bp; 



60 

obj.my_ci = ci; 



61 

clear fcf sf p ci 



62 

end 



63 




64 

function set_val(obj) 



65 

obj.my_ci.dev_type = 1; 



66 

obj.my_ci.power_src = 0; 



67 

obj.my_ci.rec_idle = 0; 




68 ob j .my_ci . sec_cap = 0; 

69 ob j .my_ci . allocate_add = 1; 

70 end 

71 

72 function rsn = get_rsn{obj) 

73 rsn = obj.rsn; 

74 end 

75 

76 function initialize (obj ) 

77 global ts 

78 struct_init (ob j ) ; 

79 set_val (ob j ) ; 

80 name = strcat (obj .name, '_send'); 

81 obj.send_t = timer (' Name name, ' TimerFcn ', @ (-i,-i) send (obj ) 

, 'BusyMode' , 'drop' , 'ExecutionMode' , 'fixedRate 

Period' ,ts/4); 

82 name = strcat (obj .name, '_parse'); 

83 obj.parse_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) parse (. . 

obj), 'ExecutionMode' , 'fixedRate' , 'BusyMode' , 'drop' , ' .. 
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Period' ,ts/4); 

84 name = strcat (obj .name, '_p'); 

85 obj.p_t = timer ( 'Name name, ' TimerFcn @ (- 1 ,-i) parse_wia (. . 

obj), 'ExecutionMode' , 'singleshot' ); 

86 name = strcat (obj . name, '_data'); 

87 %obj.data_t = timer {'Name', name, ' TimerFcn@ -i).. . 

send_data(obj),'ExecutionMode','fixedRate','StartDelay 
',15*ts, 'BusyMode', 'drop', 'Period',32 *ts); 

88 obj.data_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) send_data 

(ob j) , ' ExecutionMode ' , ' fixedRate ' , ' BusyMode ' , ' drop ' , ' . 
Period' ,1); 

89 name = strcat (obj .name, '_assoc'); 

90 ob j . assoc_t = timer ( ' Name ' , name, ' TimerFcn ' , @ (->, . 

assoc_func(obj), 'ExecutionMode' , 'fixedRate' , 'Period' , 
ts/10); 

91 name = strcat (obj . name, '_rsn'); 

92 obj.rsn_t = timer (' Name ', name, ' TimerFcn ', @ (-i,-i) inc_rsn (. . 

obj), 'ExecutionMode' , 'fixedRate' , 'StartDelay ', 1 . 

TasksToExecute' , 32, 'Period', ts); 

93 end 

94 

95 function prop = get_prop (ob j, property) 

96 prop = obj . (property) ; 

97 end 

98 

99 function set_prop (ob j , property, value) 

100 obj. (property) = value; 

101 end 

102 

103 function set_long_add (ob j, add) 

104 ob j .my_long_address = strcat (' ffffff ff ' , dec2hex (add, 8) 

); 

105 end 

106 

107 function start (obj) 

108 assoc_timer (ob j ) ; 

109 parse_timer (ob j ) ; 

110 send_timer (ob j ) ; 

111 data_timer (ob j ) ; 

112 end 
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113 


end 


114 end 


B.2 Functions 

B.2.1 asn timer.m 


1 % asn_tiiner . m 

2 % This function starts the time that controls the incrementing of ... 

the 

3 % absolute slot number (ASN) for the network. It can take in a ... 

value to 

4 % Initialize the ASN based on the ASN obtained from a beacon. 

5 

6 function asn_timer() 

7 try 

8 asn_t = timer ( ' Name ' , ' asn ' , ' Timer Fen ' , @ {-i, -i) inc_asn {),'... 

BusyMode' , 'queue' , 'StartDelay' ,1, 'ExecutionMode 

fixedRate' , 'Period' ,1); 

9 start(asn_t); 

10 catch e 

11 fprintf {' Caught exception: %s\n', e.message); 

12 end 

13 end 


B.2.2 assoc func.m 


1 % assoc_func.m 

2 % This function is called by the assoc timer 

3 

4 function assoc_func(obj) 

5 if obj.my_ci.dev_type == 0 

6 if obj.pan_coord 

7 return 

8 

9 elseif obj.assoc 
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10 


11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 


Stop(obj.assoc_t); 

beacon_tiiner (ob j ) ; 

else 

ob j.i = ob j.i + 1; 

pause(.05); % a slight pause to let all the data ... 

gather 

if obj.i > 1000 

obj.set_pan_coord; 
obj.set_pan_id(hex2dec{ 'dcba' )) ; 
asn_tiiner (ob j ) ; 
obj.assoc = 1; 

end 

end 

elseif obj.my_ci.dev_type == 1 
if obj.assoc 

stop(obj.assoc_t); 

data_timer = timer( 'Name' , 'client-data' , 'TimerFcn' ,@( ... 
-I, -i) send_data (ob j ) , ' ExecutionMode ' , ' f IxedRate 
Period' ,15); 


27 end 

28 end 

29 end 


B.2.3 assoc timer.m 


1 

% assoc_timer.m 


2 

% This timer checks the status of 

device association. 

4 

function assoc_timer(obj) 


5 

try 


6 

start (obj.assoc_t); 


7 

catch e 


8 

fprintf (' Caught exception 

%s\n', e.message); 

9 

end 


10 

end 
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B.2.4 bcn_parse_wia.m 


1 % bcn_parse_wia.m 


2 % This function parses the payload of a beacon frame. 

4 function bcn_parse_wia(obj) 


5 

obj.bcn_payload.cluster_ 

id = bin2dec(obj.rx.payload(1:8)); 

6 

obj.bcn_payload.asn = bin2dec(obj.rx.payload{9:56)); 

7 

obj.bcn_payload.time_val 

= bin2dec(obj.rx.payload(57:72)); 

8 

obj.bcn_payload.next_bcn 

_chan = bin2dec(obj.rx.payload(73:80)).. . 

9 end 

r 


B.2.5 

beacon.m 


1 % beacon.m 


2 % This function is called by 

3 

4 function beacon(obj) 

the beacon timer 

5 

obj.bcn_timestamp = tic; 


6 

obj.tx.fcf.frame_type = 

0; 

7 

transmit(obj); 


8 end 



B.2.6 

beacon_timer.m 



1 % beacon_timer.m 

2 % This timer sets the frequency at which beacons are transmitted ... 


by a 

3 % networking device. 

4 

5 function beacon_timer(obj) 

6 try 

7 start(obj.beacon_t); 

8 catch e 

9 fprintf {' Caught exception: %s\n', e.message); 
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10 


end 


11 end 


B.2.7 cc timer.m 


1 % cc_timer.in 

2 % This timer sets the frequency at which clear channel assessments... 

(CCA) are 

3 % made. 

4 

5 function cc_timer(obj) 

6 try 

7 start(obj.cc_t); 

8 catch e 

9 fprintf {' Caught exception: %s\n', e.message); 

10 end 

11 end 


B.2.8 channel.m 


1 %channel.m 

2 % This function simulates transmitted data through a channel. ... 

Currently it 

3 % is noiseless. The signal is placed in neighbor channels after a ... 

delay to 

4 % simulate transmit time. 

5 

6 function channel(obj,tx_sig) 

7 delay = 100*length(tx_sig)/250000; % using increasing time by ... 

2 orders of magnitude for simulations 

8 pause(delay) 

9 for a=l:length(obj.n_table) 

10 ob j . n_table {a} . chan=tx_sig; 

11 buffer = ob j . n_table {a} . get_prop ( ' buf f er ' ) ; 

12 buffer {numel (buffer)+1} = tx_sig; 

13 ob j . n_table { a } . chan= ' ' ; 
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14 ob j . n_table {a}. set_prop (' buffer ' , buffer); 

15 end 

16 end 


B.2.9 

channel_check.m 



1 % channel_check.m 



2 % This function collects the data when the 

channel is no 

longer ... 

clear. 



4 function channel_check(obj) 



5 

if -lisempty (ob j . chan) 



6 

if isempty(obj.buffer) 



7 

obj.buffer{1} = obj.chan; 



8 

obj.chan = '' ; 



9 

elseif -istrcmp (obj .buffer{numel (obj 

.buffer)}, obj 

.chan) 

10 

obj.buffer{numel(obj.buffer) +1} 

= obj.chan; 


11 

obj.chan = '' ; 



12 

end 



13 

end 



14 end 




B.2.10 

check_assoc.m 




1 % check_assoc.m 

2 % This channel checks the association of the device and parses . . . 


pertinent 

3 % information. 

4 

5 function check_assoc(obj) 

6 global t 

7 cmd_parse_802154(obj); 

8 if -istrcmp (ob j .my_short_address, ' f fff ' ) 

9 obj.pan_id = obj.rx.p.src_pan_id; 

10 ob j . pan_coord_add = ob j . rx. p . src_add; 

11 ob j . parent_add = ob j . pan_coord_add; 
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12 ob j . tx . f cf . src_mode = 2; 

13 text = street (obj .name, '_associated' ) ; 

14 disp (text) 

15 end 

16 end 


B.2.11 cmd_parse_802154.m 


1 % cmd_parse_802154.m 

2 % This function parses the payload of a IEEE 802.15.4 command ... 

frame. 


3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 


function cmd_parse_802154(obj) 
switch obj.rx.p.cmd_type 
case 1 

obj.rx.ci.dev_type = bin2dec(obj.rx.payload(2)); 
obj.rx.ci.power_src = bin2dec(obj.rx.payload(3)); 
obj.rx.ci.rec_idle = bin2dec(obj.rx.payload(4)); 
obj.rx.ci.sec_cap = bin2dec(obj.rx.payload(7)); 
obj.rx.ci.allocate_add = bin2dec(obj.rx.payload(8)); 
case 2 

% Association response 24 bits 
if obj.assoc 

obj.tx.payload = obj.rx.payload; 

else 

obj.my_short_address = hex_conv(obj.rx.payload ... 
(1:16),2); 

obj.cluster_id = hex_conv(obj.rx.payload(1:8),2); 
obj.assoc = bin2dec(obj.rx.payload(17:24))+1; 

end 

case 3 

% Disassociation reason 8 bits 
dis_reas = bin2dec(obj.rx.payload); 

case 5 

% Time Synchronization 
pan_id = obj.rx.payload(1:16); 


50 








29 

coord_add 

= obj.rx.payload(17:32); 

30 

chan_num = 

^ obj.rx.payload{33:40); 

31 

short_add 

= obj.rx.payload(41:56); 

32 

chan_page 

= obj.rx.payload{57:64); 

33 



34 

otherwise 


35 



36 

end 


37 

end 



B.2.12 create wia frame.m 


1 % create_wia_frame.m 

2 % This function creates the MAC layer frame for IEEE 802.15.4. 

3 

4 function frame = create_wia_frame(obj) 

5 global t 

6 

7 switch obj.tx.fcf.frame_type 

8 case 0 


9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 


frame = beacon_frame(obj); 

case 1 

frame = data_frame(obj, obj.tx.payload); 

case 2 

frame = ack_frame(obj); 

case 3 

frame = cmd_frame(obj); 

otherwise 

disp( 'error’ ) 

end 

end 


%% Beacon Frame 

function frame = beacon_frame(obj) 
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27 

global asn 


28 

if isempty(obj.send_buf) 


29 

obj.tx.fcf.frame_pend = 0; 


30 

obj.tx.p.pend_add = dec2bin(0,8); 


31 

else 


32 



33 

obj.tx.fcf.frame_pend = 1; 


34 

teinp_short = ' ' ; 


35 

teinp_long = ' ' ; 


36 

1 = 0; 


37 

l_J- 

II 

o 


38 

for a = 1 :nuinel (obj .pend_add) 


39 

if length(obj.pend_add{a}) == 4 


40 

1 = i+1; 


41 

temp_short = strcat(temp_short,hex_conv( ... 


obj.pend_add{a},1)); 


42 

elseif length(obj.pend_add{a}) == 16 


43 

j = j+1; 


44 

temp_long = strcat(temp_long,hex_ 

conv(obj.pend_i 


{a},1)) ; 


45 

end 


46 

end 


47 

obj.tx.p.pend_add = strcat(dec2bin(i,3), 

'O', dec2bin(j, 


, 'O', temp_short, temp_long); 


48 



49 

end 


50 



51 

fcf = strcat(dec2bin(obj.tx.fcf.frame_type, 3) 

, dec2bin(0,1), 


dec2bin(obj . tx . fcf . frame_pend,1) ... 


52 

, dec2bin(0 , 1) , dec2bin(l,l) 

, dec2bin(0,3) 

53 

, dec2bin(0,2), dec2bin(obj . 

tx.fcf.version, 


, dec2bin(obj . tx . fcf . src_ 

_mode, 2 ) ) ; 

54 



55 

src_pan_id = dec2bin(obj.pan_id,16); 


56 

src_add = hex_conv(obj.my_short_address,1); 


57 

add_info = strcat(src_pan_id, src_add); 


58 



59 

superframe_spec = strcat(dec2bin(obj . tx . sf . BO 

, 4) , dec2bin( . 


obj.tx.sf.S0,4), dec2bin{obj.tx.sf.finCapslot,4) 
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60 


, dec2bin(0,1), dec2bin(0,1), dec2bin( ... 
obj.pan_coord,1) ... 

61 , dec2bin (ob j . tx . sf . assoc_permit, 1) ) ; 

62 

63 payload = strcat(dec2bin(obj.bcn_payload.cluster_id,8), ... 

dec2bin(asn,48), dec2bin(obj.bcn_payload.time_val,16), ... 

dec2bln(obj.bcn_payload.next_bcn_chan,8)); 


64 

65 frame = strcat(fcf, dec2bln(obj.tx.p.b_seq_num,8), add_info, ... 

superframe_spec ... 

66 , dec2bin (0, 8) , ob j . tx . p . pend_add , payload); 

67 

68 obj.tx.p.b_seq_num = inc_seq_num(obj.tx.p.b_seq_num); 

69 

70 end 

71 

72 %% Data Frame 

73 function frame = data_frame(obj,payload) 

74 ob j . tx . f cf . dest_mode = 2; 

75 ob j . tx . f cf . src_mode = 2; 

76 obj.tx.p.src_add = obj.my_short_address; 

77 

78 dest_pan_id = dec2bin (ob j . tx. p . dest_pan_id, 16) ; 

79 dest_add = hex_conv (ob j . tx. p . dest_add, 1) ; 

80 src_add = hex_conv (ob j .tx.p. src_add, 1) ; 

81 add_info = strcat(dest_pan_id, dest_add, src_add); 

82 

83 fcf = frame_ctrl (ob j ) ; 

84 

85 frame = strcat (fcf, dec2bin(obj.tx.p.d_seq_num,8), add_info, ... 

payload); 


86 

87 obj.tx.p.d_seq_num = inc_seq_num(obj.tx.p.d_seq_num); 


89 end 

90 

91 %% Ack Frame 

92 function frame = ack_frame (ob j ) 

93 

94 fcf = frame_ctrl (ob j ) ; 
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frame = street(fcf, dec2bin(obj.rx.p.d_seq_num,8)); 


95 

96 

97 

98 end 

99 

100 %% Cmd Frame 

101 function frame = cmd_frame (ob j ) 


102 

103 

104 

105 

106 

107 

108 

109 

110 
111 
112 

113 

114 

115 

116 
117 


cmd = struct('assoc_req' 
, 'assoc_res' 
, 'disassoc' 

, 'data_req' 


switch obj.tx.p.cmd_type 

case 1 % association request 
if obj.assoc 

dest_pan_id = dec2bin(obj.tx.p.dest_pan_id,16); 
if obj.pan_coord_add 

dest_add = hex_conv(obj.pan_coord_add,1); 

else 

dest_add = hex_conv(obj.parent_add,1); 

end 

src_add = hex_conv(obj.tx.p.src_add,1); 
add_info = street(dest_pan_id, dest_add, src_add) 


118 

119 


120 


121 

122 

123 

124 

125 

126 

127 

128 

129 

130 


payload = street( dec2bin(0,l) , dec2bin( ... 
obj.tx.ci.dev_type,1) , dec2bin( . . . 

obj.tx.ci.power_src,1) , dec2bin( ... 

obj.tx.ci.rec_idle, 1) ... 

, dec2bin(0,2) , dec2bin(obj.tx.ci.sec_cap,1) 
, dec2bin(obj.tx.ci.allocate_add, 1) ) ; 


obj.tx.fcf.ack_req = 1; 

obj.tx.fcf.dest_mode = 2; 

obj.tx.fcf.src_mode = 3; 

obj.tx.p.dest_pan_id = obj.pan_id; 

if obj.pan_coord_add 

obj.tx.p.dest_add = obj.pan_coord_add; 

else 


obj.tx.p.dest_add = obj.rx.p.src_add; 

end 
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131 


132 

133 

134 

135 

136 

137 


138 

139 

140 

141 

142 

143 

144 

145 
145 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 
161 
162 

163 

164 

165 


obj.tx.p.src_add = obj.my_long_address; 
dest_pan_id = dec2bin(obj.tx.p.dest_pan_id,16); 
dest_add = hex_conv(obj.tx.p.dest_add, 1) ; 
src_add = hex_conv(obj.tx.p.src_add,1); 
add_info = strcat(dest_pan_id, dest_add, src_add) 

payload = strcat ( dec2bin(0,l) , dec2bin( .. . 
obj.tx.ci.dev_type,1) , dec2bin ( . .. 

obj.tx.ci.power_src,1) , dec2bin( ... 

obj.tx.ci.rec_idle,1) ... 

, dec2bin(0,2) , dec2bin(obj.tx.ci.sec_cap,1) 
, dec2bin(obj.tx.ci.allocate_add, 1) ) ; 

end 

case 2 % association response 

if length(obj.rx.p.src_add) == 16 
ob j . tx . f cf . dest_inode = 3; 

else 

ob j . tx . f cf . dest_inode = 2; 

end 

dest_pan_id = dec2bin(obj.tx.p.dest_pan_id,16); 
dest_add = hex_conv(obj.rx.p.src_add,1); 
src_add = hex_conv(obj.my_short_address,1); 
add_info = strcat(dest_pan_id, dest_add, src_add); 
if obj.pan_coord 

address = new_add(obj); 

payload = strcat( hex_conv(address,1) , dec2bin.. 

(0,8) ); 

else 

payload = obj.tx.payload; 

end 

case 3 % dissassociate 

case 4 % data request 

obj.tx.fcf.frame_pend = 0; 

dest_pan_id = dec2bin(obj.tx.p.dest_pan_id,16); 
dest_add = hex_conv(obj.rx.p.src_add,1); 
if obj.assoc 

obj.tx.fcf.src_mode = 2; 
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166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 
181 

182 end 

183 

184 %% Frame Control Field 

185 function fcf = frame_ctrl (ob j ) 

186 

187 fcf = strcat {dec2bin (ob j . tx. f cf . f rame_type, 3) , dec2bin {0, 1) , ... 

dec2bin(obj.tx.fcf.frame_pend, 1) ... 

188 , dec2bin (ob j . tx . fcf . ack_req, 1) , dec2bin ( . . . 

obj.tx.fcf.pan_comp,1), dec2bin(0,3) ... 

189 , dec2bin (ob j . tx . fcf . dest_mode, 2) , dec2bin ( . . . 

obj.tx.fcf.version,2), dec2bin(. .. 
obj.tx.fcf.src_mode,2)); 

190 end 


src_add = hex_conv(obj.my_short_address, 1); 

else 

obj.tx.fcf.src_mdoe = 3; 

src_add = hex_conv(obj.my_long_address,1); 

end 

add_info = strcat(dest_pan_id, dest_add, src_add); 
payload = '' ; 

end 

fcf = frame_ctrl(obj) ; 

frame = strcat(fcf, dec2bin(obj.tx.p.d_seq_num,8), add_info, ... 
dec2bin(obj.tx.p.cmd_type,8), payload); 

obj.tx.p.d_seq_num = inc_seq_num(obj.tx.p.d_seq_num); 


B.2.13 data timer.m 


1 % data_timer.m 

2 % This function starts the time that controls the incrementing of ... 

the 

3 % relative slot number (RSN) for the network. 
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5 function data_timer(obj) 

6 try 

7 start(obj.data_t); 

8 catch e 

9 fprintf {' Caught exception: %s\n', e.message); 

10 end 

11 end 


B.2.14 get_asn.m 


1 % get_asn.m 

2 % Function to retrieve the value of asn 

3 

4 function r = get_asn() 

5 global asn 

6 r = asn; 

7 end 


B.2.15 hex_conv.m 


1 % hex_conv.m 

2 % This function converts bits to hex and hex to bits. Makes data ... 

more 

3 % readable. Currently required for storing and parsing of data. 

4 

5 function output = hex_conv{input, type) 

6 switch type 

7 case 1 

8 output = hex2bin(input); 

9 case 2 

10 output = bin2hex (input) ; 

11 end 

12 end 

13 

14 function bin = hex2bin (input) 

15 bin = ' ' ; 
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16 


for a=l:length(input) 

17 bin = strcat (bin, dec2bin (hex2dec (input (a) ) , 4 ) ) ; 

18 end 

19 end 

20 

21 function hex = bin2hex (input) 

22 hex = ' ' ; 

23 for a=l: 4 : length (input) 

24 hex = strcat(hex, dec2hex(bin2dec(input(a:at3)) , 1)) ; 

25 end 

26 hex = lower (hex); 

27 end 


B.2.16 inc asn.m 


1 % inc_asn.in 

2 % This function increments the absolute slot number; 

3 

4 function inc_asn 

5 global asn 

6 global t_asn 

7 t_asn = tic; 

8 asn = asn+1; 

9 if -i(asn < hex2dec ( ' f f f f f f f f f f f f ' ) ) 

10 asn = 0; 

11 end 

12 end 


B.2.17 inc_seq_num.m 


1 % inc_seq_num.m 

2 % This function increments the sequence number of the MAC layer ... 

frames. 

3 

4 function new_seq_num = inc_seq_num(seq_num) 

5 new_seq_num = seq_num + 1; 
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6 


if -1 (new_seq_num < 255) 

7 new_seq_num = 0; 

8 end 

9 end 


B.2.18 new add.m 


% new_add.in 

% This function produces 16 bit short addresses during the joining... 
process 

% for requesting devices. 

function next_add = new_add{obj) 

if length(obj.rx.p.src_add) == 16 
if obj.rx.ci.dev_type == 0 %ffd 

cluster_id = hex2dec(obj.next_rt_address); 
obj.next_leaf_address{cluster_id+l} = {0}; 
next_add = strcat(dec2hex{cluster_id,2),dec2hex{ ... 

obj.next_leaf_address{cluster_id+l}{1},2)); 
obj.next_rt_address = dec2hex(hex2dec{ . . . 
obj.next_rt_address) +1) ; 
elseif obj.rx.ci.dev_type == 1 % rfd 

next_add = strcat(obj.cluster_id, dec2hex(numel( ... 

obj.next_leaf_address{1}),2)); 
obj.next_leaf_address{1}{hex2dec(next_add)+1} = numel(.. . 
obj.next_leaf_address{1}) ; 

end 

elseif length(obj.rx.p.src_add) == 4 

cluster_id = obj.rx.p.src_add(1:2); 
ind_c = hex2dec(cluster_id); 

next_add = strcat(cluster_id, dec2hex(numel(.. . 

obj.next_leaf_address{ind_c+l}),2)); 
ind_l = hex2dec(next_add(3:4)); 

obj.next_leaf_address{ind_c+l}{ind_l+l} = numel(.. . 
obj.next_leaf_address{ind_c+l}); 


end 


end 
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B.2.19 parse.m 


1 % parse.m 

2 % This function is called by the parse timer 

3 

4 function parse(obj) 

5 if -lisempty (obj .buffer) 

6 obj.rec_frame = obj.buffer{1}; 

7 obj.buffer(1) = []; 

8 parse_wia(obj) ; 

9 end 

10 end 


B.2.20 parse_timer.m 


1 % parse_timer.m 

2 % This timer sets the frequency at which received data is parsed ... 

by the 

3 % device. 

4 

5 function parse_timer(obj) 

6 try 

7 name = strcat(obj.name, '_parse'); 

8 start (obj.parse_t) 

9 catch e 

10 fprintf (' Caught exception: %s\n', e.message); 

11 end 

12 end 


B.2.21 parse_wia.m 


1 % parse_wia.m 

2 % This function parses the IEEE 802.15.4 MAC layer. All higher ... 

level data 

3 % will be in the payload when parsing is complete. 
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5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 


function parse_wia(obj) 

data = obj.rec_frame; 
obj.rec_frame = ' ' ; 

SHR = data(1:40); 

PHR = binPdec{data(41:47)) ; 
data = data{49:end); 
err = 0; 

if (err 0) 

sprintf ('PCS Failed!\n') 
return 

else 

last_bit = length(data); 

ob j . rx . f cf. f raine_type = binPdec (data (1: 3) ) ; 
obj.rx.fcf.sec = binPdec(data{4)); % constant value 
ob j . rx . f cf. f raine_pend = binPdec (data (5) ) ; 
obj.rx.fcf.ack_req = binPdec(data(6)); 

obj.rx.fcf.pan_comp = binPdec{data(7)); % constant value 
obj.rx.fcf.dest_mode = binPdec(data(11:12)); 
obj.rx.fcf.version = bin2dec(data(13:14)); 
obj.rx.fcf.src_mode = bin2dec(data(15:16)); 
if obj.rx.fcf.frame_type == 0 

obj.rx.p.b_seq_num = bin2dec(data(17:24)); 

else 

obj.rx.p.d_seq_num = bin2dec(data(17:24)); 

end 

switch obj.rx.fcf.frame_type 

case 0 % beacon frame 

obj.rx.p.src_pan_id = bin2dec(data(25:40)); 
if obj.rx.fcf.src_mode == 2 % 16 bit address 

obj.rx.p.src_add = hex_conv(data(41:56),2); 
obj.rx.sf.BO = bin2dec(data(57:60)); 
obj.rx.sf.SO = bin2dec(data(61:64)); 
obj.rx.sf.finCapslot = bin2dec(data(65:68)); 
obj.rx.sf.BLE = bin2dec(data(69)); % constant 
value 

obj.rx.sf.pan_coord = bin2dec(data(71)); 
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44 


45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 


obj.rx.sf.assoc_permit = bin2dec(data(72)); 
obj.rx.p.gts = bin2dec(data(73:80)); 
obj.rx.p.pend_add = bin2dec(data(81:88)); 
obj.rx.payload = data(89:last_bit); 

elseif obj.rx.fof.src_mode == 3 % 64 bit address 
obj.rx.p.src_add = hex_conv(data(41:104) , 2) ; 
obj.rx.sf.BO = bin2dec(data(105:108)); 
obj.rx.sf.SO = bin2dec(data(109:112)); 
obj.rx.sf.finCapslot = bin2dec(data(113:116)); 
obj.rx.sf.BLE = bin2dec(data(117)); % constant 
value 

obj.rx.sf.pan_coord = bin2dec(data(118)); 

obj.rx.sf.assoc_permit = bin2dec(data(119)); 

obj.rx.p.gts = data(120:128); 

obj.rx.p.pend_add = data(129:136); 

obj.rx.payload = data(136:last_bit); 

obj.rx.payload 

end 

case 1 % data frame 

if obj.rx.fcf.dest_mode == 2 % 16 bit dest address 
obj.rx.p.dest_pan_id = bin2dec(data(25:40)); 
obj.rx.p.dest_add = hex_conv(data(41:56),2); 
if obj.rx.fcf.src_mode == 2% 16 bit src ... 
address 

obj.rx.p.src_add = hex_conv(data(57:72) , 2) 


68 

69 

70 

71 

72 

73 

74 

75 

76 


obj.rx.payload = data(73:last_bit); 
elseif obj.rx.fcf.src_mode == 3 % 64 bit src . 
address 

obj.rx.p.src_add = hex_conv(data(57:120) .. 

,2) ; 

obj.rx.payload = data(121:last_bit); 
elseif obj.rx.fcf.src_mode == 0 % no src ... 
address 

obj.rx.payload = data(57:last_bit); 

end 

elseif obj.rx.fcf.dest_mode == 3 % 64 bit dest ... 
address 

obj.rx.p.dest_pan_id = bin2dec(data(25:40)); 
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77 


obj.rx.p.dest_add = hex_conv{data(41:104),2); 


78 

if obj.rx.fcf.src_mode == 2 % 16 bit src ... 

79 

address 

obj.rx.p.src_add = hex_conv(data(105:120) . 

80 

,2); 

obj.rx.payload = data(121:last_bit); 

81 

elseif obj.rx.fcf.src_mode == 3 % 64 bit src . 

82 

address 

obj.rx.p.src_add = hex_conv(data(105:168) . 

83 

,2) ; 

obj.rx.payload = data(169:last_bit); 

84 

elseif ob j . rx . f cf . src_inode == 0 % no src ... 

85 

address 

obj.rx.payload = data(105:last_bit); 

86 

end 

87 

elseif obj.rx.fcf.dest_mode == 0 % no dest address 

88 

if obj.rx.fcf.src_mode == 2 % 16 bit src ... 

89 

address 

obj.rx.p.src_pan_id = bin2dec(data(25:40)) 

90 

r 

obj.rx.p.src_add = hex_conv(data(41:56) , 2) 

91 

r 

obj.rx.payload = data(57:last_bit); 

92 

elseif obj.rx.fcf.src_mode == 3 % 64 bit src . 

93 

address 

obj.rx.p.src_pan_id = bin2dec(data(25:40)) 

94 

f 

obj.rx.p.src_add = hex_conv(data(41:104) .. 

95 

,2); 

obj.rx.payload = data(105:last_bit); 

96 

elseif obj.rx.fcf.src_mode == 0 % no src ... 

97 

address 

obj.rx.payload = data(25:last_bit); 

98 

end 

99 

end 

100 

101 

case 2 % ack frame 

102 

103 

case 3 % cmd frame 

104 

if obj.rx.fcf.dest_mode == 2 % 16 bit dest address 
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105 


obj.rx.p.dest_pan_id = bin2dec(data(25:40)); 

106 ob j . rx .p . dest_add = hex_conv (data (41: 5 6) , 2) ; 

107 if ob j . rx. f of . src_mode == 2 % 16 bit src ... 

address 

108 ob j . rx . p . src_add = hex_conv (data (57 : 72) , 2) 


109 

110 
111 
112 
113 


114 


115 


obj.rx.p.cmd_type = bin2dec(data(73:80)); 
if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 
obj.rx.payload = data(81:last_bit); 

end 

elseif obj.rx.fof.src_mode == 3 % 64 bit src . 
address 

obj.rx.p.src_add = hex_conv(data(57:120) .. 

,2); 

obj.rx.p.cmd_type = bin2dec(data(121:128)) 


116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 

127 

128 

129 

130 


if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 

obj.rx.payload = data(129:last_bit); 

end 

elseif ob j . rx . f of . src_inode == 0 % no src ... 
address 

obj.rx.p.cmd_type = bin2dec(data(57:64)); 
if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cind_type) 
obj.rx.payload = data(65:last_bit); 

end 

end 

elseif obj.rx.fcf.dest_mode == 3 % 64 bit dest ... 
address 

obj.rx.p.dest_pan_id = bin2dec(data(25:40)); 
obj.rx.p.dest_add = hex_conv(data(41:104) , 2) ; 
if obj.rx.fcf.src_mode == 2 % 16 bit src ... 
address 

obj.rx.p.src_add = hex_conv(data(105:120) . 

,2) ; 

obj.rx.p.cmd_type = bin2dec(data(121:128)) 


131 if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 

132 obj . rx . payload = data (12 9 : last_bit) ; 

133 end 
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134 


3 %64 bit src .. 


elseif ob j . rx. f cf . src_inode == 
address 

135 ob j . rx. p . src_add = hex_conv (data (105 :168) . 

, 2 ) ; 

136 ob j . rx. p . cmd_type = bin2dec (data (169 :176) ) 


137 if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 

138 obj . rx.payload = data (177 : last_bit) ; 

139 end 

140 elseif ob j . rx . f cf . src_inode == 0 % no src ... 

address 

141 ob j . rx. p . cmd_type = bin2dec (data (105 :112) ) 


142 

143 

144 

145 

146 

147 


148 


if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 

obj.rx.payload = data(113:last_bit); 

end 

end 

elseif obj.rx.fcf.dest_mode == 0 % no dest address 
if obj.rx.fcf.src_mode == 2 % 16 bit src ... 
address 

obj.rx.p.src_pan_id = bin2dec(data(25:40)) 


149 


obj.rx.p.src_add = hex_conv(data(41:56) , 2) 


150 

151 

152 

153 

154 


155 


obj.rx.p.cmd_type = bin2dec(data(57:64)); 
if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 
obj.rx.payload = data(65:last_bit); 

end 

elseif obj.rx.fcf.src_mode == 3 % 64 bit src . 
address 

obj.rx.p.src_pan_id = bin2dec(data(25:40)) 


156 


157 


obj.rx.p.src_add = hex_conv(data(41:104) .. 

, 2 ) ; 

obj.rx.p.cmd_type = bin2dec(data(105:112)) 


158 if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 

159 obj . rx . payload = data (113 : last_bit) ; 

160 end 


65 




161 


162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 


175 

176 

177 

178 

179 


180 

181 


elseif ob j . rx . f cf . src_inode == 0 % no src ... 
address 

obj.rx.p.cmd_type = bin2dec(data(25:32)); 
if -lany ( [ 4, 6, 7 ] == ob j . rx . p . cmd_type) 
obj.rx.payload = data(33:last_bit); 

end 

end 

end 

otherwise 

disp (' Illegal Fraine_Type ' ) 
return 

end 

if any(strcmp(obj.rx.p.src_add, {obj.my_short_address, ... 
obj.my_long_address})) 
return 

elseif ob j . rx. f cf . f rame_type == 0 && -lOb j . pan_coord 
parsed(obj) 
return 

elseif any(strcmp(obj.rx.p.dest_add, {obj.my_short_address ... 
, obj.my_long_address, 'ffff'})) 
parsed(obj) 
return 


182 end 

183 end 

184 end 


B.2.22 parsed.m 


1 % parsed.m 

2 % This function determines device responses and actions to ... 

received data. 

3 

4 function parsed(obj) 

5 global time_delay 

6 if obj.pan_coord 
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7 


8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 


35 


36 


if (ob j . rx . f cf . ack_req == 1) && (-iany([0,2] == ... 

ob j . rx . f cf . f raine_type) ) && -lany (ob j . rx .p . d_seq_num == . 

ob j . ack;_table) 

obj.last_seq_num = obj.rx.p.d_seq_num; 
obj.tx.fcf.frame_type = 2; 
transmit(obj); 

end 

if (obj.rx.fcf.frame_type == 1) 
for a=l:numel(time_delay) 

if strcmp(obj.rx.payload, time_delay{a}{1}) 

time_delay{a}{3} = toe(time_delay{a}{2}); 
disp(time_delay{a}{3}) 

end 

end 

end 

if (obj.rx.fcf.frame_type == 3) 
if (obj.rx.p.cmd_type == 1) 
cmd_parse_802154(obj); 

obj.tx.ci.dev_type = obj.rx.ci.dev_type; 
obj.tx.fcf.frame_type = 3; 
obj.tx.p.cmd_type = 2; 
tx = obj.tx; 

obj.pend_add{numel(obj.pend_add)+1} = ... 
obj.rx.p.src_add; 

obj.send_buf{numel(obj.send_buf)+1} = {... 
obj.rx.p.src_add, tx}; 
elseif (obj.rx.p.cmd_type == 4) 
if -lisempty (ob j . send_buf) 

if any(strcmp(obj.rx.p.src_add, obj.pend_add)) 
for a=l:numel(obj.send_buf) 

if any(strcmp(obj.rx.p.src_add, ... 
obj.send_buf{a}{1})) 
obj.tx = obj.send_buf{strcmp (.. . 

obj.rx.p.src_add, obj.send_buf{a 
} {1} ) } { 2 } ; 

obj.send_buf(strcmp( ... 

obj.rx.p.src_add, obj.send_buf{a 
}{1})) = []; 

obj.rx.ci.dev_type = ... 
obj.tx.ci.dev_type; 
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37 


38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 


obj.pend_add(strcmp( ... 

obj.rx.p.src_add, obj.pend_add{a . 
}) ) = [ ] ; 
transmit(obj); 
break; 

end 

end 

else 

obj.tx.fof.frame_type = 1; 

obj.tx.p.dest_add = obj.tx.p.src_add; 

obj.tx.payload = 

transmit(obj); 

end 

end 

end 

end 

elseif -lOb j .pan_coord 

if (ob j . rx . f of . ack_req == 1) && (-iany([0,2] == ... 

obj.rx.fof.frame_type)) 
obj.tx.fof.frame_type = 2; 
transmit(obj); 

end 

if (obj.rx.fof.frame_type == 0) 
obj.bcn_timestamp = tic; 
obj.rsn = 0; 

obj.pan_id = obj.rx.p.src_pan_id; 
if obj.rx.sf.pan_coord == 1 

obj.pan_coord_add = obj.rx.p.src_add; 

end 

if (obj.assoc == 0) && (obj.waiting == 0) && strcmp (... 

obj.my_short_address, 'ffff') 
obj.tx.fcf.frame_type = 3; 
obj.tx.p.cmd_type = 1; 
obj.tx.ci = obj.my_ci; 
obj.waiting = 1; 
transmit(obj); 

end 

if obj.rx.fcf.frame_pend == 1 
if ob j . rx . p . pend_add 0 

pend_add = dec2bin(obj.rx.p.pend_add,8); 


68 




73 


74 

75 

76 

77 

78 


i = bin2dec(pend_add(1:3)) ; 
j = bin2dec(pend_add(5:7)); 
temp = {}; 
if i ^ 0 

for a = 1:i 

temp{numel(temp)+1} = hex_conv{ ... 

obj.rx.payload(1:16) , 2 ); 
obj.rx.payload = obj.rx.payload(17:end 


80 

81 

82 

83 

84 


end 

end 

if j ^ 0 

for a = 1:j 

temp{numel(temp)+1} = hex_conv{ ... 

obj.rx.payload(1:64) , 2 ); 
obj.rx.payload = obj.rx.payload(65:end 


86 

87 


89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 


end 

end 

if any(strcmp(obj.my_short_address, temp)) || 
any(strcmp(obj.my_long_address, temp)) 
obj.tx.fof.frame_type = 3; 
obj.tx.p.cmd_type = 4; 
transmit(obj); 

end 

end 

end 

bcn_parse_wia(obj) ; 

elseif (obj.rx.fof.frame_type == 1) && obj.my_ci.dev_type 
== 0 

%disp(obj.name) 

obj.tx.fcf.frame_type = 1; 

obj.tx.p.dest_add = obj.pan_coord_add; 

obj.tx.fof.ack_req = 0; 

obj.tx.payload = obj.rx.payload; 

transmit(obj); 

elseif (obj.rx.fof.frame_type == 3) 

if obj.rx.p.cmd_type == 1 && obj.my_ci.dev_type == 0 
cmd_parse_802154(obj) ; 
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lOS 

107 

108 

109 

110 
111 
112 

113 

114 

115 

116 

117 

118 

119 

120 
121 
122 

123 

124 

125 

126 

127 

128 

129 

130 

131 


132 

133 

134 

135 

136 

137 

138 


obj . join_table{nuinel (obj . join_table) } = ... 

obj.rx.p.src_add; 
obj.tx = obj.rx; 

obj.tx.p.src_add = obj.my_short_address; 
obj.tx.fof.src_mode = 2; 
obj.waiting = 1; 
transmit(obj); 

elseif obj.rx.p.cmd_type == 2 

if obj.assoc && obj.my_ci.dev_type == 0 
cmd_parse_802154(obj) ; 
obj.rx.p.src_add = obj.join_table{1}; 
obj.join_table{1} = []; 
obj.tx = obj.rx; 
obj.tx.fcf.dest_mode = 3; 
obj.tx.p.src_add = obj.my_short_address; 
tx = obj.tx; 
obj.waiting = 0; 

obj.pend_add{numel(obj.pend_add)+1} = ... 
obj.rx.p.src_add; 

obj.send_buf{numel(obj.send_buf)+1} = {... 
obj.rx.p.src_add,tx}; 

else 

check_assoc(obj); 

end 

elseif (obj.rx.p.cmd_type == 4) && obj.my_ci.dev_type 
== 0 

if -lisempty (ob j . send_buf) 

for a=l:numel(obj.send_buf) 

if (strcmp(obj.rx.p.src_add, obj.send_buf{a 

}{!})) 

obj.tx = obj.send_buf{strcmp (.. . 

obj.rx.p.src_add, obj.send_buf{a ... 
}{!})} {2 }; 
transmit(obj) 

end 

end 

end 

end 

end 

end 
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139 end 


B.2.23 send data.m 


1 % send_data.m 

2 % This function sends data frame with an arbitrary payload. 

3 

4 function send_data(obj) 

5 global asn 

6 if mod(asn,32) == obj.alloc (1)-1 

7 obj.tx.fcf.frame_type = 1; 

8 obj.tx.fcf.ack_req = 0; 

9 obj.tx.p.dest_add = strcat(obj.my_short_address(1:2) , '00 ' ) ... 


10 obj.tx.payload = strcat(hex_conv(obj.my_short_address,1) . 

dec2bin{obj.tx.p.d_seq_num,8),hex_conv( 'deadbeef ',!)); 

11 

12 transmit (obj ) ; 

13 end 

14 end 


B.2.24 send.m 


1 % send.m 

2 % This function sends data during the allocated timeslot. 

3 % It is also used to measure the end-to-end-delay. 

4 function send(obj) 

5 global asn 

6 global time_delay 

7 global t_asn 

8 

9 if mod(asn,32) == 0 

10 ob j . set_prop (' count 0 ) ; 

11 end 

12 if -lisempty (ob j . send_data_buf) 

13 tx_sig = ob j . send_data_buf {1} ; 
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14 


if mod(asn,32) == obj.alloc(obj.count+1) 

15 obj. count = obj. count + 1; 

16 pause {1-toc (t_asn) ) 

17 start = tic; 

18 if obj.tx.fcf.frame_type == 1 && obj.my_ci.dev_type == ... 

1 


19 send_data (ob j ) ; 

20 time_delay {numel (time_delay) +1} 

start}; 


21 

22 

23 

24 

25 

26 


end 

obj.send_data_buf(!) = [] ; 
channel(obj, tx_sig); 

end 

end 

end 


{obj.tx.payload, ... 


B.2.25 send_timer.m 


1 % send_timer.m 

2 % This function starts the time that controls the incrementing of ... 

the 

3 % relative slot number (RSN) for the network. 

4 

5 function send_timer(obj) 

6 try 

7 start(obj.send_t); 

8 catch e 

9 fprintf (' Caught exception: %s\n', e.message); 

10 end 

11 end 


B.2.26 set rec val.m 


1 % set_rec_val.m 

2 % This function sets network information on the device based on a ... 

received 
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3 


beacon, 


"6 

4 

5 function set_rec_val(obj) 

6 obj.tx.sf.BO = obj.rx.sf.BO; 

7 obj.tx.sf.SO = obj.rx.sf.SO; 

8 obj.tx.sf.finCapslot = obj.rx.sf.finCapslot; 

9 obj.tx.sf.assoc_permit = obj.rx.sf.assoc_permit; 

10 

11 obj.pan_id = ob j . rx . p . src_pan_id; 

12 ob j . tx . p . dest_pan_id = ob j . rx . p . src_pan_id; 

13 ob j . tx. p . dest_add = ob j . rx. p . src_add; 

14 

15 if ob j . assoc 

16 ob j . tx . f cf . src_mode = ob j . rx . f cf . src_mode; 

17 end 

18 if (ob j . rx . sf .pan_coord == 1) 

19 ob j . pan_coord_add = ob j . rx . p . src_add; 

20 end 

21 end 


B.2.27 slotted csma.m 


1 % slotted_csma.m 

2 % This function performs slotted carrier sense multple access / ... 

collision 

3 % avoidance (CSMA/CA). 

4 

5 function status = slotted_csma(obj,frame) 

6 


7 %disp('entered csma') 


8 

NB = 0; 



9 

CW = 2; 



10 

bit_rate = 250000; 

%max 

bit_rate 

11 

maxMacCSMABackoffs 

= 4; 

%default value 

12 

macMaxBE = 5; 



13 

macMinBE = 3; 



14 




15 

t_backoff = .032;% 

(20*4) 

1 /bit_rate; %symbols 
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16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 


t_superframe_slot = 1; %(3*t_backoff)*2^obj.tx.sf.SO; 
N_backoff = 3*2^obj.tx.sf.SO; 

BE = macMinBE; 

while {NB < maxMacCSMABackoffs) 

t_elapsed = toe(obj.bcn_timestamp); 

backoff_boundary = {ceil(t_elapsed/t_backoff)); 

next_boundary = (backoff_boundary+randi([0,2^BE-1])); 

pause (next_boundary*t_backoff) 

disp(obj.chan) 

while isempty(obj.chan) 

CW = CW - 1; 

next_boundary = next_boundary + 1; 
if CW == 0 

channel(obj,frame); 
status = 1; 
return 

end 

end 

CW = 2; 

NB = NB + 1; 

BE = min{BE+l, macMaxBE); 

end 

sprintf( ’Failure!\n’ ) 

status = 0; 

return 

end 


B.2.28 transmit.!!! 


1 % transmit.m 

2 % This function transmits the data during the proper timeslot ... 

based on 

3 % which timeframe of the superframe it is in. 

4 

5 function transmit(obj) 

6 global time_delay 
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7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 end 


B.2.29 


global asn 

type = {'beacon', 'data' ... 

, 'ack' , 'cmd' }; 

name = strcat(obj.name,type{obj.tx.fof.frame_type+l}); 

disp(name) % display 

frame = create_wia_frame(obj) ; 

preamble = '00000000000000000000000000000000'; 

SFD = '11100101 ' ; 

SHR = strcat(preamble, SFD); 
if length(frame) < 128*8 

PHR = strcat(dec2bin(ceil(length(frame)/8 ),7 ),' 0 ') ; 

else 

disp(' frame is too long') 

end 

tx_sig = strcat(SHR, PHR, frame); 
obj.tx_frame = tx_sig; 

if any([l,3] == obj.tx.fcf.frame_type) 

obj.ack_table(numel(obj.ack_table)tl) = obj.tx.p.d_seq_num; 
end 

if any(obj.tx.fcf.frame_type == [0,2]) 
channel(obj,tx_sig) 

elseif any(obj.tx.fcf.frame_type == 3) 
status = slotted_csma(obj, tx_sig); 
if status 

for a=l:numel(obj.send_buf) 

obj.send_buf(strcmp(obj.rx.p.src_add, ... 
obj.send_buf{a}{1})) = []; 

end 

end 

elseif (obj.tx.fcf.frame_type == 1) 

send_data_buf = obj.get_prop( 'send_data_buf' ); 
send_data_buf(numel(send_data_buf)+1} = tx_sig; 
obj.set_prop( 'send_data_buf' ,send_data_buf); 

end 


wia structs.m 
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1 


wia_structs.m 

These are structs to hold data for the network and makes for ... 


2 % 


simpler 

3 % device initialization. 

4 

5 superframe = struct( 'BO' , 0 ... 

6 , 'SO' , 0 . . . 

7 , 'finCapslot' , 0 ... 

8 , 'BLE' , 0 . . 

9 , 'pan_coord' ,0 


10 



, ' a s s o c_ 

permit' 

11 





12 

fcf 

= struct( 

'frame_type' 

, 0 . . . 

13 



' sec' 

, 0 . . . 

14 



'frame_pend' 

, 0 . . . 

15 


/ 

'ack_req' 

, 0 . . . 

16 


/ 

'pan_comp' 

, 1 . . . 

17 


/ 

'dest_mode' 

, 0 . . . 

18 


/ 

'version' 

, 3 . . . 

19 


/ 

'src_mode' 

, 0); 

20 





21 

p = 

struct( 

'pend_add' 

, 0 . . . 

22 



'd_seq_num' 

, 0 . . . 

23 



'b_seq_num' 

, 0 . . . 

24 



'src_pan_id' 

, 0 . . . 

25 



'dest_pan_id' 

, 0 . . . 

26 


/ 

'dest_add' 

, 0 . . . 

27 


/ 

'src_add' 

, 0 . . . 

28 


/ 

'cmd_type' 

, 0); 

29 





30 

ci 

= struct( 

'dev_type' 

, 0 . . . 

31 



'power_src' 

, 0 . . . 

32 



'rec_idle' 

, 0 . . . 

33 



'sec_cap' 

, 0 . . . 

34 



'allocate_add' 

, 0); 

35 





36 

bp 

= struct 

' asn' 

, 0 . . 

37 


/ 

' cluster_id' 

, 0 . . 

38 



'time_val' 

, 0 . . 
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39 


'next_bcn_chan' 


, 0 ); 

40 


41 

wia_cmd = struct { 'dlsl_fc' 


, 0 . 

42 

, 'dlsl_cmd_ 

id' 

, 0 . 

43 

, 'cal_time_ 

val' 

, 0) ; 

44 




45 

sf_states = struct( 'cap' , 

0 . 


46 

, 'cfp' 

0 . 


47 

, 'intra' , 

0 . 


48 

, 'inter' , 

0 . 


49 

, 'sleep' , 

0) ; 



B.2.30 setup.m 


1 % setup.m 

2 % This script is used to initialize and test all of the devices 

3 

4 %%% global variables - section required for nodes 

5 % global t 

6 % t = t i c ; 

7 % global ts 

8 % t s = 1 ; 

9 % 

10 % global time_delay 

11 % global t_asn; 

12 % tlme_delay = {}; 

13 % 

14 % global asn 

15 % a s n = 0 ; 

16 

17 %%% Tests 

18 

19 % %%% Single Cluster with 1 Node 

20 % a=wia_ffd; 

21 % b=wia_ffd; 

22 % c=wia_rfd; 

23 % 

24 % a. set_pan_coord; 
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25 % initialize (a) ; 

26 % a . set_pan_id (hex 2 dec (' abed' ) ) ; 

27 % a. name = 'ffd_l'; 

28 % a . set_long_add {1) ; 

29 % 

30 % b. name = 'ffd_2'; 

31 % initialize (b) ; 

32 % b.pan_id = hex2dec ( ' abed' ) ; 

33 % b . tx . p. sre_pan_id = hex2dee ( ' abed' ) ; 

34 % b . tx . p. dest_pan_id = hex2dee ( ' abed') ; 

35 % b . set_long_add (2 ) ; 

36 % b. my_short_address = '0100'; 

37 % b.assoe = 1; 

38 % b.alloe = [24:31] ; 

39 % 

40 % e. name = 'rfd_l'; 

41 % initialize (e) ; 

42 % e.pan_id =hex2dee ( ' abed') ; 

43 % e . tx . p. sre_pan_id = hex2dee ( ' abed' ) ; 

44 % e . tx . p. dest_pan_id = hex2dee ( ' abed') ; 

45 % e . set_long_add {4 ) ; 

46 % e. my_short_address = '0101'; 

47 % e.assoe = 1; 

48 % e . alloe= [16] ; 

49 % 

50 % a . n_table= [ b} ; 

51 % b . n_table= [ a, e} ; 

52 % e . n_table= [b} ; 

53 % 

54 % a. start; 

55 % 

56 % % eluster 1 

57 % b. start; 

58 % e. start; 

59 

60 %%% Single Cluster with 8 Nodes 

61 % a=wia_ffd; 

62 % b=wia_ffd; 

63 % e=wia_rfd; 

64 % d=wia_rfd; 
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65 

g, 

0 

e=wia_rfd; 



66 

g, 

0 

f=wia_rfd; 



67 

g_ 

0 

g=wia_rfd; 



68 

g_ 

o 

h=wia_rfd; 



69 

g_ 

0 

i=wia_rfd; 



70 

g_ 

0 

j=wia_rfd; 



71 

g_ 

0 




72 

g_ 

o 

a. set_pan_coord; 



73 

g, 

0 

initialize(a); 



74 

g, 

0 

a.set_pan_id(hex2dec('abed')) ; 


75 

g, 

0 

a.name = 'ffd_l'; 



76 

g_ 

0 

a.set_long_add{1) ; 



77 

g, 

0 

a . alloc = [0]; 



78 

g_ 

0 




79 

g_ 

o 

b.name = 'ffd_2'; 



80 

g_ 

0 

initialize(b); 



81 

g_ 

0 

b.pan_id = hex2dec( 

'abed'); 


82 

g_ 

0 

b . tx.p.src_pan_id = 

hex2dec('abed'); 

83 

g_ 

o 

b.tx.p.dest_pan_id 

= hex2dec(' 

abed'); 

84 

g, 

0 

b . set_long_add(2 ) ; 



85 

g_ 

0 

b. my_short_address 

= '0100'; 


86 

g, 

0 

b.assoc = 1; 



87 

g, 

0 

b.alloc = [24:31]; 



88 

g, 

0 




89 

g_ 

0 

c.name = 'rfd_l'; 



90 

g_ 

o 

initialize(c) ; 



91 

g_ 

0 

c.pan_id = hex2dec( 

'abed'); 


92 

g_ 

0 

c . tx.p.src_pan_id = 

hex2dec('abed' ) ; 

93 

g_ 

0 

c.tx.p.dest_pan_id 

= hex2dec(' 

abed'); 

94 

g_ 

o 

c . set_long_add{3) ; 



95 

g, 

0 

c.my_short_address 

= '0101'; 


96 

g, 

0 

c.assoc = 1; 



97 

g_ 

0 

c.alloc = [16]; 



98 

g, 

0 




99 

g, 

0 

d.name = 'rfd_2'; 



100 

g_ 

0 

initialize(d); 



101 

g_ 

o 

d.pan_id =hex2dec(' 

abed'); 


102 

g_ 

0 

d.tx.p.src_pan_id = 

hex2dec('abed'); 

103 

g_ 

0 

d. tx.p.dest_pan_id 

= hex2dec(' 

abed'); 

104 

g_ 

0 

d.set_long_add{4) ; 




79 




0102 ' ; 


105 

g, 

0 

d.my_short_address = '0102'; 


106 

g, 

0 

d.assoc = 1; 


107 

g_ 

0 

d.alloc=[17]; 


108 

g_ 

o 

g, 

o 


109 

g_ 

0 

e.name = 'rfd_3'; 


110 

g_ 

o 

initialize(e); 


111 

g_ 

0 

e.pan_id =hex2dec('abed'); 


112 

g_ 

o 

e.tx.p.src_pan_id = hex2dec('abed'); 

113 

g, 

0 

e.tx.p.dest_pan_id = hex2dec( 

'abed'); 

114 

g, 

0 

e.set_long_add{5) ; 


115 

g, 

0 

e.my_short_address = '0103'; 


116 

g, 

0 

e.assoc = 1; 


117 

g, 

0 

e.alloc = [18]; 


118 

g_ 

0 

g, 

o 


119 

g_ 

o 

f.name = 'rfd_4'; 


120 

g_ 

0 

initialize(f); 


121 

g_ 

o 

f.pan_id =hex2dec('abed'); 


122 

g_ 

0 

f . tx . p . src_pan_id = hex2dec('abed') ; 

123 

g_ 

o 

f . tx . p . dest_pan_id = hex2dec( 

'abed') ; 

124 

g, 

0 

f . set_long_add(6) ; 


125 

g, 

0 

f . my_short_address = '0104'; 


126 

g, 

0 

f.assoc = 1 ; 


127 

g, 

0 

f.alloc = [19] ; 


128 

g, 

0 

g, 

o 


129 

g_ 

0 

g.name = 'rfd_5'; 


130 

g_ 

o 

initialize(g) ; 


131 

g_ 

0 

g.pan_id =hex2dec('abed') ; 


132 

g_ 

0 

g . tx . p . src_pan_id = hex2dec('abed '); 

133 

g_ 

0 

g . tx . p . dest_pan_id = hex2dec( 

'abed') ; 

134 

g_ 

o 

g . set_long_add{7) ; 


135 

g, 

0 

g . my_short_address = '0105'; 


136 

g, 

0 

g.assoc = 1; 


137 

g, 

0 

g.alloc = [20]; 


138 

g, 

0 

g, 

o 


139 

g, 

0 

h.name = 'rfd_6'; 


140 

g_ 

0 

initialize (h); 


141 

g_ 

o 

h.pan_id =hex2dec('abed'); 


142 

g_ 

0 

h.tx.p.src_pan_id = hex2dec('abed'); 

143 

g_ 

o 

h.tx.p.dest_pan_id = hex2dec( 

'abed'); 

144 

g_ 

0 

h.set_long_add{8); 
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145 

g, 

0 

h.my_short_address = '0106'; 

146 

g, 

0 

h.assoc = 1; 

147 

g_ 

0 

h.alloc = [21] ; 

148 

g_ 

o 

g, 

o 

149 

g_ 

0 

1.name = 'rfd_7'; 

150 

g, 

o 

initialize (i); 

151 

g_ 

0 

i.pan_id =hex2dec('abcd'); 

152 

g_ 

o 

1 .tx.p.src_pan_id = hex2dec('abcd'); 

153 

g, 

0 

1 .tx.p.dest_pan_id = hex2dec('abed'); 

154 

g, 

0 

1 .set_long_add{9) ; 

155 

g, 

0 

1.my_short_address = '0107'; 

156 

g, 

0 

1 .assoc = 1; 

157 

g, 

0 

1 .alloc = [22]; 

158 

g_ 

0 

g, 

o 

159 

g_ 

o 

j.name = 'rfd_8'; 

160 

g_ 

0 

initialize(j); 

161 

g_ 

o 

j.pan_id =hex2dec('abcd'); 

162 

g_ 

0 

j.tx.p.src_pan_id = hex2dec('abcd'); 

163 

g_ 

o 

j . tx . p . dest_pan_id = hex2dec('abed') ; 

164 

g, 

0 

j . set_long_add(10) ; 

165 

g, 

0 

j . my_short_address = '0108'; 

166 

g, 

0 

j . assoc = 1; 

167 

g, 

0 

j . alloc = [23] ; 

168 

g, 

0 


169 

g_ 

0 

a . n_table={b} ; 

170 

g_ 

o 

b . n_table={a,c,d,e,f,g,h,i,j}; 

171 

g_ 

0 

c . n_table={b} ; 

172 

g_ 

o 

d . n_table={b} ; 

173 

g_ 

0 

e . n_table={b} ; 

174 

g_ 

o 

f . n_table={b} ; 

175 

g, 

0 

g . n_table={b} ; 

176 

g, 

0 

h . n_table={b} ; 

177 

g, 

0 

1 . n_table={b} ; 

178 

g, 

0 

j . n_table={b} ; 

179 

g, 

0 


180 

g_ 

0 

a. start; 

181 

g_ 

0 


182 

g_ 

0 

% cluster 1 

183 

g_ 

o 

b. start; 

184 

g_ 

0 

c. start; 
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185 % d. Start; 

186 % e. start ; 

187 % f. start ; 

188 % g . start; 

189 % h. start; 

190 % i. start ; 

191 % j. start ; 

192 % 

193 %%% Two Clusters with 4 nodes each 

194 % a=wia_ffd; 

195 % b=wia_ffd; 

196 % c=wia_ffd; 

197 % 

198 % d=wia_rfd; 

199 % e=wia_rfd; 

200 % f=wia_rfd; 

201 % g=wia_rfd; 

202 % h=wia_rfd; 

203 % i=wia_rfd; 

204 % j=wia_rfd; 

205 % k=wia_rfd; 

206 % 

207 % a . set_pan_coord; 

208 % initialize (a) ; 

209 % a . set_pan_id (hex2dec (' abed' ) ) ; 

210 % a. name = 'ffd_l'; 

211 % a . set_long_add {1) ; 

212 % 

213 % b. name = 'ffd_2'; 

214 % initialize (b) ; 

215 % b.pan_id = hex2dec (' abed' ) ; 

216 % b.pan_coord_add = '0000'; 

217 % b . tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

218 % b . tx . p. dest_pan_id = hex2dec ( ' abed') ; 

219 % b . set_long_add {2 ) ; 

220 % b. my_short_address = '0100'; 

221 % b. assoc = 1; 

222 % b.alloc = [24:27] ; 

223 % 

224 % c . name = ' f fd_3 ' ; 
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225 % initialize (c) ; 

226 % c.pan_id = hex2dec (' abed' ) ; 

227 % c. pan_coord_add = '0000'; 

228 % c . tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

229 % e . tx . p. dest_pan_id = hex2dee ( ' abed') ; 

230 % e . set_long_add {3) ; 

231 % e. my_short_address = '0200'; 

232 % e.assoe = 1; 

233 % e.alloe = [28:31]; 

234 % 

235 % d.name = 'rfd_l'; 

236 % initialize (d) ; 

237 % d.pan_id =hex2dee ( ' abed') ; 

238 % d. tx . p. sre_pan_id = hex2dee ( ' abed' ) ; 

239 % d. tx . p. dest_pan_id = hex2dee ( ' abed') ; 

240 % d. set_long_add { 4 ) ; 

241 % d.my_short_address = '0101'; 

242 % d.assoe = 1; 

243 % d. alloe= [16]; 

244 % % 

245 % e . name = ' rf d_2 ' ; 

246 % initialize (e) ; 

247 % e.pan_id =hex2dee ( ' abed') ; 

248 % e . tx . p. sre_pan_id = hex2dee ( ' abed' ) ; 

249 % e . tx . p. dest_pan_id = hex2dee ( ' abed') ; 

250 % e . set_long_add {5) ; 

251 % e.my_short_address = '0102'; 

252 % e.assoe = 1; 

253 % e . alloe = [ 17 ] ; 

254 % % 

255 % f.name = 'rfd_3'; 

256 % initialize ( f) ; 

257 % f.pan_id =hex2dee ( ' abed') ; 

258 % f . tx . p. sre_pan_id = hex2dee ( ' abed' ) ; 

259 % f . tx . p. dest_pan_id = hex2dee ( ' abed') ; 

260 % f . set_long_add { 6) ; 

261 % f. my_short_address = '0103'; 

262 % f.assoe = 1; 

263 % f. alloe = [18]; 

264 % % 
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265 % g.name = 'rfd_4'; 

266 % initialize (g) ; 

267 % g.pan_id =hex2dec ('abed') ; 

268 % g. tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

269 % g. tx . p. dest_pan_id = hex2dec ( ' abed') ; 

270 % g . set_long_add {7 ) ; 

271 % g. my_short_address = '0104'; 

272 % g. assoc = 1; 

273 % g.alloc = [19]; 

274 % % 

275 % h.name = 'rfd_5'; 

276 % initialize (h) ; 

277 % h.pan_id =hex2dec ( ' abed') ; 

278 % h . tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

279 % h . tx . p. dest_pan_id = hex2dec ( ' abed') ; 

280 % h . set_long_add { 8) ; 

281 % h.my_short_address = '0201'; 

282 % h. assoc = 1; 

283 % h.alloc = [16]; 

284 % % 

285 % i . name = ' rf d_6 ' ; 

286 % initialize (i ) ; 

287 % i.pan_id =hex2dec ( ' abed') ; 

288 % i . tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

289 % i . tx . p. dest_pan_id = hex2dec ( ' abed') ; 

290 % i . set_long_add { 9) ; 

291 % i.my_short_address = '0202'; 

292 % i. assoc = 1; 

293 % i. alloc = [17]; 

294 % % 

295 % j .name = ' rfd_7 ' ; 

296 % initialize ( j ) ; 

297 % j.pan_id =hex2dec ( ' abed') ; 

298 % j . tx . p. src_pan_id = hex2dec ( ' abed' ) ; 

299 % j . tx . p. dest_pan_id = hex2dec ( ' abed') ; 

300 % j . set_long_add {10 ) ; 

301 % j .my_short_address = '0203'; 

302 % j . assoc = 1 ; 

303 % j . alloc = [ 18 ] ; 

304 % % 
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305 % k.name = 'rfd_8'; 

306 % initialize (k) ; 

307 % k.pan_id =hex2dec ('abed') ; 

308 % k . tx . p . src_pan_id = hex2dec ( 

309 % k . tx . p. dest_pan_id = hex2dec 

310 % k . set_long_add {11) ; 

311 % k. my_short_address = '0204'; 

312 % k.assoc = 1; 

313 % k. alloc = [19]; 

314 % 

315 % 


316 

g, 

0 

a.n_table= 

[b] 

r 

317 

g, 

0 

b.n_table= 

[a. 

d, e,f, g}; 

318 

g_ 

0 

c.n_table= 

[a. 

h, i,j, k}; 

319 

g_ 

0 

d.n_table= 

[b] 

r 

320 

g_ 

0 

e.n_table= 

[b] 

r 

321 

g_ 

0 

f.n_table= 

[b] 

r 

322 

g_ 

0 

g.n_table= 

[b] 

r 

323 

g_ 

0 

h.n_table= 

[c] 

r 

324 

g, 

0 

i.n_table= 

[c] 

r 

325 

g_ 

0 

j.n_table= 

[c] 

r 

326 

g_ 

0 

k.n_table= 

[c] 

r 

327 

g, 

0 




328 

g, 

0 

a. start; 



329 





330 

g_ 

o 

cluster 1 



331 

g_ 

0 

b. start; 



332 

g_ 

0 

d. start; 



333 

g_ 

0 

e. start; 



334 

g_ 

o 

f. start; 



335 

g, 

0 

g. start; 



336 





337 

g_ 

0 

cluster 2 



338 

g, 

0 

c. start; 



339 

g, 

0 

h. start; 



340 

g_ 

0 

i . start; 



341 

g_ 

o 

j . start; 



342 

g, 

o 

k. start; 




'abed'); 
( 'abed') 
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